CSO

Oct 04

elephant repellent

By alberg CSO, deep thoughts Comments Off

An elephant, a mouse, or a ghost?

Sometimes I feel like I’m selling elephant repellent:

I identify a particular species of elephant (for example, compromise of our networks due to spearphish delivered email).

I find examples of this particular elephant showing up on the networks of similar organizations.

I try to calculate the damage which said elephant would cause (which nearly always includes hard to quantify types of damage to things like “reputation” and “trust.”)

I run some tests to show that, yes, some of our users would in fact happily open the gates of the village to this particular elephant by clicking on just about any link emailed to them.

I then look for some sort of elephant repellent – a policy, a procedure, education, some technology or a combination of the above to keep said pachyderm from rampaging through our village.

Of course, elephant repellent is not free… there is a cost in productivity, usability, share of user attention, or cold hard cash. If the risk to cost ratio seems right, I take action, spraying elephant repellent all around the village. Time passes. No elephants show up, I proudly announce the success of this particular elephant repellent and start looking for the next elephant to repel. Of course, the question remains as to whether the lack of elephantine activity in the village is due to the repellent, well, repelling or whether the elephants never would have shown up at the village gates in the first place. (or whether the elephants will get clever and will show up next week and trample the place in spite of my efforts)

Elephants come in a variety of sizes. Some of them can rampage through the village and leave a wide path of destruction. Other elephants sound scary, but end up being more mouse like in their impact. If you ring the elephant alarm every day, the villagers (in particular, the village elders) are going to pay less attention as time goes on. Elephants are also unpredictable – sometimes they show up, other times, they pass your village by and trample the village next door. You gotta pick your elephants. I guess that is part of the “art” side of infosec (anticipating howls of protest from the quantitative guys on this).

At least Infosec people don’t usually have to deal with elephants which kill people – let’s say, a devastating earthquake. The stakes are, of course, very high in these cases and the village elders can get very angry when these elephants make it through the village gates. In fact, six seismologists and a government official are currently on trial for manslaughter in Italy for failing to predict an earthquake which struck the L’Aquila region in April, 2009. Yes, you read that right… While this episode may be an outlier, it does point out the rising expectations of all sorts of village elders (both corporate and governmental) as to the risk experts’ ability to make very accurate predictions of risks – expectations which may not be possible to achieve. Call it the “CSI effect” – we are used to seeing all sorts of cool technology providing definite answers to questions and we have come to expect that all questions can be answered in this way.

We as Infosec professionals have to strike a balance between the quantitative and qualitative approaches to choosing which elephants to worry about. To add to the problem, some of us (particularly in highly regulated industries like finance) are given a set of elephants which we must repel by regulators and other stakeholders. These “default elephants” may pose less risk to the village than other, less famous, elephants, but we have to divert resources (and repellent) to deal with them in order to stay in business.

So… the takeaway? We need to share best practices for spotting, measuring and evaluating risk from both a qualitative and quantitative point of view. Organizations like the FS-ISAC (and other industry ISACS) where we can share information in confidence with our peers are a great place to do this. We need to up the level of information sharing in these fora – while it is great to get lists of bad IP addresses and URLs, I’d also like to see more (anonymous) sharing of stories about risks and repellents. The more people looking at the elephant and reporting on what it did when it visited their villages the better picture we can put together.

Jul 01

in which i dare disagree with security industry luminary bruce schneier

By alberg CSO, hacks, malware, online security, Paranoid Peeps Comments Off

It’s not often that I disagree with Bruce Schneier, one of the leading lights of the security world… however, I do have a teensy weensy bone to pick with him regarding one of his recent blog postings. A recent test conducted by the Department of Homeland Security on its employees found (to no one’s surprise) that people are prone to pick up unidentified USB drives and pop them into their computers with abandon, providing nefarious personages the ability to infect their systems with malware. Schneier took issue with the following quote from a security expert regarding the study:

Mark Rasch, director of network security and privacy consulting for Falls Church, Virginia-based Computer Sciences Corp., told Bloomberg: “There’s no device known to mankind that will prevent people from being idiots.”

In Schneier’s view, the idiocy really rests with operating system manufacturers who allow their products to access untrusted USB devices with providing the user with any protection and that the users are simply doing the best that they can under the circumstances. This is where I disagree.

While OS manufacturers should be doing a better job of securing their products against unknown USB devices, in the current situation users need to exercise extreme caution in what they stick into their computers’ USB ports. Until we have better tools to mitigate this risk, users have to play an active role in protecting themselves and their organizations from USB borne threats. There has been a lot of news coverage (and at least at my organization, security awareness training) to let people know about the risks of USB devices of uncertain provenance. I happen to think that the people in my organization are smart (and good looking) enough to remember a few very basic security messages and behaviors needed to protect our systems and networks:

Don’t open links or files from strangers
Don’t open unexpected/strange links or files (that seem to be) from friends
Don’t take USB candy from strangers

Yes, I know that application of these rules will not provide 100% protection from malware, but following them will definitely mitigate the risks involved, which is really the best we can hope for at this time.

So, Bruce, you are still my hero, but I think we need to hold our colleagues to a slightly higher standard in terms of their role in protecting our computers and networks.

Oh, and as for Mr. Rasch’s “idiot” comment, I think he was a bit rough on users in terms of his choice of language. I would have said “boneheaded” or “Homer Simpson-like” instead. This is why I am beloved at my workplace.

May 02

cloud security outlook… still, well, cloudy

By alberg best practices, CSO, malware, online security, worst practices Comments Off

Cloud storage provider DropBox provides a great example of some of the security issues that individuals and companies face when entrusting sensitive data to the cloud. Over the past few weeks, DropBox has made the news twice regarding its security and we all know that making the news is generally not a good thing when it comes to security.

Dropbox’s first issue came up in early April, when a security researcher named Derek Newton discovered a significant weakness in the service’s authentication mechanism. One of the primary benefits of DropBox is that it allows the user to set up synchronized file systems across multiple devices. When files are added to, modified on or deleted from any DropBox enabled computer, iPhone, iPad or other device, the changes are automatically replicated to all of the other devices associated with the user’s account. This is a really useful feature for many people. In order for this file synchronization to work properly, you need to install a piece of software on each device used to access your account. Newton found that the Windows DropBox client stores the information needed to access the DropBox server in a configuration file which contains a “host ID” used to authenticate to DropBox. Simply by copying this file to another computer with the DropBox software installed on it, an attacker would have full read/write access to the files in the DropBox account.

This opens up a whole range of possibilities for attackers. For instance, it would be possible to write malware which specifically looks for the DropBox configuration file and sends it back to the attacker. Once an attacker has the configuration file, they would have continued access to the compromised DropBox account even after the malware was removed from the user’s computer. The user would have to remove their own computer from the list of devices allowed to access their DropBox account and reinstall the software to close the door on the attacker.

As of today, the vulnerability still exists… DropBox plans to rollout a software update which would make the configuration file useless on a second machine, but has not provided a timeline for remediation. I would recommend not using DropBox until such a fix is made.

DropBox also made the news for a change in their terms of service. The original terms of service assured users that since their files were stored in encrypted form on the DropBox servers, DropBox employees could not peek into their data. Well, it turns out that this is not exactly the case. A “limited number” of DropBox employees do, in fact, have the ability to decrypt user files in order to comply with law enforcement requests for data in connection with an investigation. Now, I understand that DropBox wants to be a good corporate citizen, but there is a significant distinction between “our employees can’t read your data” and “only some of our employees can read your data.” I applaud DropBox for making their terms of service clearer (and more accurate), but this incident (and the reaction from DropBox users) is an example of one of the major problems facing users and organizations when they make the decision to move their data to the cloud.

The problem is two fold… customers don’t know the right questions to ask and vendors just don’t seem to understand that users require security for their cloud data, even if they cannot exactly describe what security measures they are looking for. A recent Ponemon survey on cloud computing providers’ views of the security of their services showed that among survey respondents (who we can assume are amongst the more security aware providers), vendors had the least confidence regarding some important security features of their services, such as

Their ability to authenticate users before granting access
Their ability to prevent or curtail external attacks
Their ability to encrypt sensitive or confidential information assets whenever feasible
Their ability to determine the root cause of cyber attacks

It is clear to me that many individuals and business are rushing in to take advantage of the cost advantages and convenience of cloud computing without knowing how safe or unsafe their information is while it rests in the cloud. The efforts of organizations like the Cloud Security Alliance to develop baseline language, best practices and assessment tools are a step in the right direction, but the road to cloud security is still foggy and treacherous.

Mar 07

app stores and security

By alberg CSO, hacks Comments Off

As personal handheld devices like smartphones and tablets become part of employees’ technical arsenals, the security of those devices begins to impact the corporate environment. No matter how many times we tell people not to store sensitive corporate information on these devices, there will always be a subset of people who do so. They are not being malicious; rather they see these new technologies as a way to improve their productivity and are frustrated with corporate IT departments’ unwillingness or inability to support them.

Once corporate information is on these devices, security professionals need to be concerned about not only the inherent security of the device, but the trustworthiness of totally unrelated applications which the employee installs on their device.

In the past week, Google removed more than 50 applications from the Android Market after a user discovered that they were actually pirated versions of popular Android applications which had been modified to contain a piece of malware dubbed “DroidDream,” which sends the attacker a variety of information about the device it is installed on and more importantly, provides a mechanism allowing the attacker to load and execute additional code onto the phone or tablet.

To Google’s credit, they reacted to this news quite quickly - within minutes of being notified of the problem, they removed the malware laden applications from the Android Market and later sent commands to all Android devices to remove the applications from users devices. However, over 50,000 downloads of the rogue applications were made prior to the discovery of the malware and it is unknown how many of the affected users’ devices may have downloaded additional nefarious applications which were not removed by Google’s actions.

The basic problem here is that the structure of Android Market does not include any review of applications prior to their being put on sale. Say what you like about Apple’s draconian control of its iOS platforms and App Store, but the App Store is much more likely to catch and prevent the distribution of malware than Android Market.

Of course, iOS users who decide to “jailbreak” their devices, thus allowing them to install applications from third parties outside of the App Store are just as much at risk as Android Market users. Jailbreaking an iOS device is very easy and users may be tempted to jailbreak in order to obtain software which is not available from the App Store.

All of this complicates life for the corporate IT manager who wants to make these amazing new devices part of their IT ecosystem. If users are allowed to use their personal devices for corporate business, we need to worry about what applications they are installing on these devices. As they are not corporate owned or controlled, we can’t really tell people what apps they should or should not install or prohibit them from jailbreaking their device. If we decide to roll out corporate owned iOS and Android devices, we end up with new platforms to support without the security and configuration tools which allow us to protect our desktop and laptop computing devices.

So what do we do? For now, I think that educating our users about the risks they face while using their personal devices is job one. We need to make users understand that jailbreaking an iOS device significantly reduces the level of security on the device. We need to explain to users that Android applications are not pre reviewed in any meaningful way by Google.

As far as enterprise use of these new devices, I think that Google and Apple need to get working on some enterprise management software that allows corporations to securely configure and manage these devices. Ideally, it should be possible to create a separate encrypted corporate partition where work information is stored. This partition should need to periodically phone home to check to make sure that the device is still authorized to access corporate information and to pick up policy updates.

Consumer devices are clearly the wave of the future in enterprises – but we need help from the vendors to make these devices safe for corporate use.

Oct 03

why hack when you can just ask?

By alberg best practices, CSO, hacks Comments Off

At this past summer’s Def Con hacking convention, the folks at www.social-engineer.org decided to run a “Capture the Flag” competition to highlight the risks posed by social engineering, the art of extracting information from employees in order to make hacking a company’s systems or processes easier. The test was run under a number of constraints; participants were not allowed to ask for passwords, credit card numbers and the like, due to legal concerns. Instead, they were tasked with finding out things like the target companies’ operating systems in use, PBX vendors, VPN equipment, payday dates, trash handling and the like. A total of 15 companies were targeted for open source research and follow up calls. The results?

14 out of the 15 companies provided one or more of the requested pieces of information.
Only 7 companies gave the attackers any resistance to answering the questions they were asked.
Out of 135 calls made, only 11 individuals put up any resistance to answering the attackers’ queries.

Some interesting (and depressing) take aways from this report…

Most employees offered no resistance to the attackers’ requests for information. Those that did offer resistance could often be persuaded to give up the goods with a little more conversational kung-fu on the part of the attacker. Of course, it is possible that the contest’s rules against asking for really sensitive personal information like passwords and credit card numbers may have come into play here. I would think that the employees would have put up a bit more of a fight if the information being asked for was perceived to be more valuable. This being said, getting information of low perceived value can help the attacker build a more convincing cover story for later attempts to get to the crown jewels.

Eighty percent of employees called were willing to visit a web address supplied by the attacker. This is pretty disturbing, as it provides the attacker with a great way to collect information about victims’ computers and to install targeted malware on vulnerable interesting systems.

In many cases, the only thing that stopped an attacker from getting a particular piece of information was the employee’s ignorance or the fact that they were too busy to continue the call. In some cases, employees went out of their way to try and find the information in order to be helpful. The fact that many of the people called worked in customer or employee facing call centers seemed to work in the attackers’ favor – after all, the call center exists to be helpful.

Attackers calling to ask “survey questions” were able to extract information from their victims pretty consistently. The context of a survey allows the attacker to ask a series of questions and when the call is delivered in an engaging manner, the employee can be coaxed into providing lots of information. Security awareness programs should include periodic reminders that employees should not provide answers to questions posed by callers “as part of a survey.” At my office, I ask employees to transfer these types of calls to Security so we can mess with them.

Ex-employees can also be a source of information about your company. An attacker armed with a list of recently departed employees could gather information by calling them posing as an employment recruiter. In this context, asking questions about systems and processes can seem innocent. It is important to have confidentiality agreements in place with employees and to remind them of their continuing obligations under those agreements after they leave the company.

While this contest was limited in its scope and realism (due to the limits on what could be asked for), I would recommend reading the report to get an idea of what we security professionals are up against. In these times of limited or shrinking budgets, closing up the security holes that result from human behavior can be a very effective – and cost effective – way to protect our organizations. Let your employees know about the threat of social engineering attacks and give them a procedure to follow when a call gets suspicious (like having them transfer the call to Security).

Let’s make the hackers work a little bit, folks!

Aug 28

ceo, cfo, pants on fire?

By alberg CSO, useful stuff Comments Off

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?

Aug 16

so long, SAS70!

By alberg best practices, CSO Comments Off

SAS70 season - the most wonderful time of the year!

Since 1992, many organizations have relied on SAS70 audit reports to determine whether their service providers’ controls are appropriately designed and effectively implemented.

In the information security field, the SAS70 has become the unofficial standard for how service providers provide assurance to their customers that their systems are safe and secure. This is not what the SAS70 was originally designed to do – SAS70 reports are supposed to focus on financial matters, but the people have spoken.

Since my employer is a service provider, we conduct an annual SAS70 Type 2 audit with an external audit partner. We then provide the resulting report to our customers’ information security and risk teams to help convince them that they can trust us with their sensitive information. This is pretty typical for the industry.

It is important to remember that the SAS70 standard simply describes the format for the report produced by the external auditor. There is no such thing as being “SAS70 Certified.” It is even more important to realize that the scope of the SAS70 report (in the form of the list of controls to be tested) is pretty much up to the organization being audited. If the organization does not want to test certain controls, they can simply leave them out of the report. For this reason, when evaluating a SAS70 report from a vendor, you need to read carefully – what is not said in the report is probably even more important than what is included. (very zen, don’t you think?)

The new SSAE 16/ISAE 3402 standards which took effect in June of this year are meant to replace the SAS70. SSAE 16 is the US version of the standard, while ISAE 3402 is the international version. These new frameworks do provide some improvements over SAS70 for those evaluating outsourcers. I am pleased with two of the changes in particular:

While the SAS70 was centered around the description of controls, SSAE 16/ISAE 3402 adds a requirement to include a description of the system being audited. This description must include transaction flows as well as significant non transaction events. While this is going to mean more reading for the recipient of a report, it also provides the recipient with much better context to evaluate whether the controls described later on are sufficient.

The new standard also requires organization to do a risk assessment and make sure that the controls that are reviewed address the risks to the system described. The service provider does not have to include the risk review in the report, but the auditor will be looking for risk/control linkages during the review process. I think that this is a good thing, especially for smaller service providers who may not have a mature enterprise risk management function, as it will force management to take stock of risks in a systematic way.

While these are welcome changes, they do not really address what I think is main problem with SAS70 as an information security assurance tool – the lack of common objective criteria to be assessed. The approach that I have taken in the SAS70 that I am responsible for is to map out all of the controls described in the report against the ISO 27002 standard, which provides provides ”established guidelines and general principles for initiating, implementing, maintaining, and improving information security management within an organization.” While my shop has not gone through the formal certification process for 27002, I feel that using the standard as a framework provides the readers of our SAS70 with some additional assurance that we are including all of the relevant infosec controls.

So, as we bid a (somewhat) fond farewell to SAS70, I look forward (somewhat) to our new, improved minty fresh SSAE 16 reports. My company will be doing our first SSAE 16 early in 2011 – I’ll report back on how the process differs from what we have done to date.

Jul 10

who’s watching the watchers? in this case, nobody

By alberg CSO, worst practices Comments Off

Friday’s Wall Street Journal featured a page 1 article (unfortunately behind a subscription paywall – less detailed but free coverage here, but you can get the full WSJ article by searching Google News for “HSBC data theft”) on a massive theft of private banking client data from HSBC. The thief was… wait for it… an HSBC infosec employee whose job it was to improve the security of the systems and databases holding that data. Said employee then shopped the data around to a number of European tax authorities as well as to competing banks. When the French police raided his parents’ home in France as part of the investigation into the theft, the data was turned over to the French tax people, resulting in collection of 1 billion euros from les tax evadeurs. Now the French tax people are sharing this treasure trove of data with their colleagues in other countries, who also expect to collect lots of back taxes.

Of course, the guy at the center of this claims he was not in it for the money – he wanted to point out flaws in HSBC security or help catch tax evaders or was working for intelligence services. (He can’t seem to decide on which story to go with…) In any event, he denies any illegal activity and stated that he copied the data to his personal computers and offsite servers as part of his normal work. HSBC states that it is against company policy to copy such data to non HSBC computers.

The story is quite interesting and raises a number of questions for security pros, organizations and law enforcement (as well as folks who like to stash their cash out of sight of the tax man).

Is France’s use of the ill gotten data and it’s further distribution of what is in effect stolen property a legitimate tool for government authorities? While there is a social good in collecting these taxes from the rich tax evaders, is this benefit outweighed by the message it sends vis a vis the rule of law?

Why was this very sensitive data not protected by some sort of DLP solution or even just old fashioned auditing and log review on the database server? Someone looking at a log and seeing this guy perform SELECT * on a sensitive database was all that would have been needed to detect this crime.

Why did this employee even have access to this data? I can’t see how his job function (in a properly designed technical and procedural environment) required the ability to view and copy database information. Changes and testing of security for that database should have been done in a separate QA environment using test data and then staged to production by another party.

My final question is one for the security community… Where does our fiduciary duty to our employers end and our responsibility as citizens start? In this case, I think that the HSBC employee was clearly in the wrong. HSBC was offering a service to it’s clients which is perfectly legal under Swiss law. The users of the service had a responsibility to report their income to their taxation authorities under the current regime. If the employee had a problem with the world of private banking, he should have gotten into a new line of work rather than resorting to theft. As for his claimed pure motives, I would have a lot less trouble believing him had he not shopped the data to competing banks. I’d also point out that it would have been reasonable for him to expect some sort of renumeration from the tax authorities for his “aid” in collecting lost revenue. His stories just don’t seem to add up.

It is important to note that this is not a problem unique to HSBC – the lapses that led to this data theft are extremely common across all industries. Heck, even the US military has data stolen through loopholes in data protection policies (and Lady Gaga).

This case is a great learning opportunity for security and risk professionals – organizations need to remember that security personnel are human and need to have appropriate controls placed on their systems access as well. In most organizations, the Internal Audit group can provide this oversight. Smaller organizations may need to resort to periodic reviews of internal security by an external consultant. In any case, make sure someone is watching the watchers!

Update 2010-07-10 2010 – Just noticed that US tax authorities are “ramping up” their investigation into whether HSBC marketed tax evasion services to US clients. Now, if they did engage in this activity, shame on them. However, if the allegations are found to be true, it still does not transform a data theft by a person in a position of trust. Had the employee involved simply contacted authorities with his concerns, the data could have been gotten by the authorities. And his shopping the data to competitors still sticks in my craw.

May 02

massachusetts kicks data protection butt!

By alberg best practices, CSO, online security Comments Off

Data protection... Massachusetts style

Now I have two things which I really like about Massachussets – The Friendly Toast in Cambridge (mmm… Caribbean waffles) and their new data protection law. As of March 1, any organization which holds personnally identifiable information (PII) about residents of the Commonwealth must attest that they have a written information security plan designed to protect that information. And that PII maust be encrypted both when it travels over the wire and when it is stored in systems. Penalties for violation are quite hefty – $5,000 per violation and per record lost.

The law also requires businesses handling MA residents’ PII to take a number of steps that they should already be doing – having someone responsible for the infosec program, identifying risks, training personnel, preventing terminated employees from accessing the PII, secure authentication and the like. You can read the entire text of the law here…

It is about time and I hope that other states (and the federal government – call me a socialist) follow Massachusetts’ lead. Requiring businesses to take some very basic and inexpensive steps to protect our information from unauthorized access is quite reasonable. It seems to me that complying with the encryption requirements can be accomplished via an SSL cert, laptop encryption software (such as BitLocker, included with Windows 7 or FileVault on Macs), and use of database encryption features are just common sense, as is having an information security plan.

Bravo, MA!

Apr 25

when was the last time we retired a security control?

By alberg CSO, deep thoughts Comments Off

This weekend, I attended the Security B-Sides Boston conference (which, by the way, I heartily recommend to all info sec types). My favorite session of the day was Josh Corman‘s “Fsck the FUD” talk… this talk was chock full of security thought leadership goodness and will probably result in a number of blog postings here at Paranoid Prose.

In his talk, Josh asked a really thought provoking question: When was the last time that the information security community retired a control? If you take a look at lists of recommended security controls from 10 or even 20 years past, you will see many of the same measures that are found in the latest PCI, COBIT and other prescriptive documents. Each year, a few new must have controls are added, much to the chagrin of CSOs and security personnel (who then have to spend more of their limited time and resources implementing new controls as well as maintaining existing ones) and to the delight of auditors (who get job security and longer audit checklists to fill out, and thus more billable hours). This approach of continuous “improvement” of security “standards” is just not scalable, given most organizations’ unwillingness to fund the corresponding infinite growth of security resources (how unreasonable!).

Why is this happening? Josh’s theory (with which I agree) is that auditors and standards writers tend to be very conservative. In their minds, once a control is written down, it becomes revealed truth, and having more controls must ensure a higher level of security, right? As a result, many organizations (especially those in heavily regulated industries like Finance, Health Care and payment card processing) seem to fear their auditors more than the attackers who the security folks are supposed to be fending off. We have to make sure that we can check all of the boxes and get “good grades” on our audits and assessments, whether or not the controls being tested are relevant and provide real protection.

This model leads to a stifling of innovation in the info sec industry, according to Corman. Since most info sec spending is concentrated around passing audits and fulfilling regulatory and compliance requirements, we continue to spend most of our time and money on legacy controls which may or may not be very effective at addressing evolving (and quite dangerous) threats. We get that warm and fuzzy feeling from passing the audit, but that does not necessarily mean that we are well protected. Security vendors respond to this pattern and concentrate their product offerings in spaces which address the tried and true controls they know that their customers need to meet. They are simply not incented to come up with new ideas and better products and their marketing departments spend most of their time figuring out how to spread FUD and convince CSOs that their existing products somehow address the mind numbingly scary threat du jour.

A couple of examples come to mind:

Anti malware software - signature based anti malware software is having a harder and harder time keeping up with the threats we expect it to protect against. More and more evil code is produced from toolkits which generate custom versions that differ from the AV vendors’ signatures just enough to slip by the defenses. In a number of recent cases, totally customized, highly targeted code has been used to infect machines of interest and extract valuable information. It seems to me that signatures are becoming less and less effective as controls against malware and that protections based on system behavior make much more sense. Yet we still buy, deploy, maintain and update lots of signature based AV software, so that we can check the proper audit boxes and vendors don’t have real incentive to come up with new and more effective defensive products.

Passwords - One of the most frequent complaints I get from users at my company is that our password policies (long passwords with different types of characters that need to be changed pretty frequently) are a pain in the posterior. I feel for them… complicated passwords that are changed frequently do provide protection against some threats, but it seems to me that the main threat to passwords today is malware which grabs the password as it is typed – and it doesn’t matter how long, complicated and frequently changed the password is. Yet, we still enforce our password policy. Part of the reason is that the policy does provide a certain level of protection against some threats, but in reality, we have kept the policy mainly because our business partners (customers, regulators, etc.) expect us to have such a policy and would look askance at us if we didn’t. (In spite of recent research suggesting that the negative economic effects of these policies may exceed their protective benefit).

So… what do we need to do as an industry? I think we need to start a dialog in which we take a long, hard look at the security controls we “require” and answer some key questions about them:

What is the threat that this control addresses?
Is the threat we are protecting against still a threat? If so, has the nature of the threat changed significantly?
How can we update the control requirements to better address the threat using currently available technology or processes?
What new technology (if any) do we need from vendors in order to address the threat as it stands today?

The big question is how to get this discussion going… conferences like Security B-Sides, Defcon and the like are great places to start talking, but we need to find a way to get the mainstream security media and standards bodies to participate… going to be giving this a bit of thought and would love to hear from you with ideas!