Interesting blog post from Graham Cluley on LastPass’ support for using the Galaxy S5′s fingerprint reader as the key to your password vault. Since the S5′s fingerprint reader has been shown to be vulnerable to low sophistication fake fingerprint attacks, he wonders whether this (admittedly) very convenient feature is worth the risk. As a LastPass user, I don’t think I would base the security of the keys to my entire digital life on this particular piece of hardware. However, this does beg the question – is the low but non zero risk of someone getting hold of your phone and fingerprint exceed the risk of using the same damn password on every site you visit? LastPass also offers a mitigation for this scenario – it is possible to specifically permission which mobile devices can access your account. If you phone is lost or stolen, it is possible to revoke that permission (if you notice the loss or theft quickly enough). This is a risk calculation that users will have to make for themselves.
A while back, I wrote about how US organizations writing social media policies need to beware of the National Labor Relations Board’s requirements that these policies not interfere with the rights of employees to discuss their working conditions or organize unions. At the time of my original post, the NLRB had released a guidance document which raised more questions than it answered. Since then, they have released additional guidance which includes a number of examples of bad policies and explains the specific problems with each. More importantly, it includes a sample policy which is in compliance with NLRB rules and which can be used as a guide in writing (or updating) your company’s social media policy. It is really worth taking a look at this document – many things that any normal, reasonable infosec professional would expect to be acceptable (ie. “don’t post confidential information to social media sites”) are not.
If you are an information professional at a publicly traded company, I would strongly suggest reading a recent blog post by Richard Bejtlich about the SEC’s requirements for the disclosure of cybersecurity breaches. Bejtlich points out that the ramifications of these requirements go well past getting in to hot water with the regulators – they also raise other risks, such as whistleblowing by employees or third parties as well as the potential for shareholder lawsuits when companies do not take the proper steps to secure information (or are perceived as not doing so). Having a conversation about this issue with your General Counsel before an incident occurs makes a lot of sense. All this being said, kudos to the SEC for recognizing the role of cybersecurity in good corporate governance.
Greetings from Washington, DC – the home of corrupt politicians, sleazy lobbyists, democracy destroying SuperPACs and Moby Dick House of Kebab. I’m here to attend ShmooCon, which is (IMHO) one of the better security cons out there. I’ll be blogging about what I learn over the next few days, so stay tuned for some cutting edge security goodness. Interested in anything specific on the schedule? Drop me a line at firstname.lastname@example.org or DM me at @alberg on the Twitter.
When Microsoft comes out with an out of cycle security advisory (and during a holiday week, no less), you know something big is up. This week’s bulletin highlights a denial of service attack and two privilege escalation vulnerabilities that affect web sites built on top of ASP.NET. The most serious privilege escalation vulnerability could allow an attacker to execute commands on a system by sending specially crafted web requests.
The denial of service issue is related to a flaw in the way that ASP.NET (as well as PHP, Ruby and Java) handle the hash tables which are used to pass information from user web inputs to the web server. By sending specially crafted requests to vulnerable web servers, it is possible to tie up all of their CPU resources and make them unavailable to legitimate users. This attack was revealed at this past week’s Chaos Communications Congress in Berlin – you can watch the presentation here.
There is a very good technical description of the DoS problem and attack here.
The DoS flaw is also present in PHP, Python, some Java web frameworks, and Ruby. Apache Tomcat 7.0.23 contains a workaround fix which limits the number of parameters accepted in a POST request. PHP version 5.4.0 will include a workaround fix for this problem, but is not yet ready for production use. Ruby version 1.9 and higher has a fix which solves the problem by randomizing the hash tables.
Given the recent ‘hacktivist’ activity we have been seeing, it would not surprise me if this attack was used against sites in the financial industry as well as in the public sector. In any case, the Microsoft patch is a must for your web facing ASP.NET systems now. The US-CERT’s vulnerability page for this issue is a good place to keep track of vendors’ responses as more platforms are found to be vulnerable.
Interesting post from security and cyberwarfare blog Digital Dao on how changes in Russian law will make it more difficult for foreign firms and investigators to track down the owners of .ru domains used for nefarious purposes. Not a positive development.
…at least according to this interesting blog post from OpenDNS’ Allison Rhodes. It makes sense to me… in the AM, we are all going through our emails, getting ready for the day to come and in a hurry to get caught up with the latest news. I saw this post as a result of being on OpenDNS’ site from here at the Agahozo Shalom Youth Village, where we are using OpenDNS to provide web filtering to keep the students away from some of the, um, racier sites on the Net. OpenDNS seems to be a really good, easy to use solution for web filtering in the cloud. If you have young web surfers at home, you might want to check it out.
The National Security Agency isn’t all about listening in on other people’s conversations or being the object of insanely paranoid fantasies. The NSA also has an Information Assurance mission, protecting guvmint computers from hackers, spies, and this guy. Now taxpayers can take advantage of the billions of dollars they have paid in to keep the NSA running… the agency has released a pretty good guide to securing home computers (PDF file) with information for Windows and Mac users. Unfortunately, it is a little bit on the techie side – you can’t just email it grandma and assume she’s good to go, but it does provide a great checklist to help you (and your colleagues) batten down those cyber-hatches. Worth a read.
A recently published research paper entitled “Detecting Deceptive Discussions in Conference Calls” provides an interesting look at lies and the liars who tell them (in this case, company CEOs and CFOs) as well as a peek into the future of of lie detection in general.
For this paper, the researchers decided to look at a group of statements by CEOs and CFOs in quarterly earnings conference calls held with investors. They specifically wanted to focus on the times when fibs may have been told on these calls. In order to find these occasions, they looked for cases where companies had to restate their financial results after the calls, or had to disclose other information such as material weaknesses in controls, late filings, changes to auditors, or form 8-K filings.
The researchers got hold of all available transcripts for US quarterly earnings conference calls between 2003 and 2007. The transcripts were formatted in XML, making them a lot easier to parse. Next, they broke down the transcripts, ignoring the “Management Discussion” parts which are presumed to be heavily scripted and vetted by legal, investor relations, marketing and other corporate types before a word is uttered. That left the “Question and Answer” parts of the calls, which tend to be more spontaneous (hence providing more opportunities for questions leading to prevarications to be asked). Finally, the statements of the CEOs and CFOs were isolated for analysis. The researchers presumed that the CEO and CFO would know the true state of the company, thus providing them with opportunities to fib to investors during the Q&A.
After analyzing the data, they found that when executives fib…
- They make more references to audience or general knowledge – “As you know…”
- They use more words linked to extreme positive emotions – “The outlook for the company is fabulous!”
- They make fewer references to shareholders value and value creation
- CEOs in particular make fewer references to themselves and use more third person and impersonal pronouns. They also use fewer words indicating non-extreme positive emotions as well as fewer “hesitation words” and words indicating certainty.
- Interestingly, when CFOs tell lies, they tend to use more words indicating certainty
While the study itself was fascinating reading, I also found the authors’ summary of the different perspectives on deception noted by other researchers in the field.
From an emotional perspective, deceivers are thought to feel guilty about their deceptions and have a fear of being caught in their lies. This leads to negative emotions, and a negative affect. According to this perspective, deceivers will make more negative comments, use more general terms and avoid referring to themselves. Their statements will tend to be short, indirect and evasive.
Taking a cognitive perspective on deception highlights the fact that it takes mental energy to lie and keep one’s story straight. This perspective suggests that deceptive statements will use more general terms and lack specific details. Again, the deceiver will avoid referring to themselves and will avoid mentioing personal experiences. Statements will tend to be shorter, to minimize the amount of keeping track that the deceiver must perform to make their narrative consistent.
Looking at deception from an attempted control perspective focuses on the deceiver’s efforts to avoid making statements which would expose their lies. This perspective also expects deceptive statements to have non specific language, few self references, and short statements with little real detail. The deceiver may inject irrelevant information into his or her statements to distract their audience. If the deceiver is well prepared, there will be more specific information, and fewer of the natural hesitations found in normal speech. This perspective also looks for lexical diversity as an indicator of deception; people telling the truth tend to repeat themselves, while deceivers seem to use a more varied vocabulary. Maybe this is why it is interesting to listen to storytellers and other “professional deceivers.”
The final perspective on deception is that of lack of embracement – in this approach, the deceiver feels uncomfortable telling a lie and appears to lack conviction in what they are saying, mainly due to the fact that their claims are not in line with their experience. Again, speaking in generalities, few slef references and short answers would be expected from a deceiver operating under this framework.
I had a few take aways from this paper:
It gave me a rational basis for the “gut feelings” we have when deciding whether a person is telling us the truth or not. I will be a lot more conscious of the structure and content of statements when making these evaluations.
I also see this type of research, when combined with technologies such as pervasive digital recording and speech recognition, as possibly marking the beginning of a time when many of the statements we make will be automatically dissected, analyzed and evaluated (possibly in real time) to indicate whether statements are true or deception. Like any other lie detection technology, this must be used with a clear understanding of its limitations. A few years ago, we were told that voice stress analysis would make it possible for our phones to tell us when someone is lying in real time; the technology has not lived up to the hype. A lot more research needs to be done here, but I think we are going to be hearing a lot more about this topic in the future.
I mean, would I lie to you?
That’s why TrueCrypt is one of my favorite open source software products – it provides full disk encryption for Windows, Mac OS X and Linux systems at an unbeatable price point (free). One of its nice features is that you can create a fully encrypted flash drive (or hard drive) on, say, a Windows system and then take that device and use it on a Mac or Linux system with TrueCrypt installed – quite handy for those of us who use different operating systems on a regular basis. For the most paranoid amongst us, you can even set up hidden encrypted volumes within encrypted volumes to further shield your data from prying eyes. Version 7 of this vital part of my personal information security toolkit was released back in July, and adds the ability to have volumes automount when they are connected to the computer as well as protection of crash dump and hibernation files on Windows 7 systems. If you haven’t had a chance to play with TrueCrypt, give it a try today!