Traditionally, hackers have chosen their targets in order to either profit financially or make a political statement (never mind the advanced persistent threats represented by nation states and powerful criminal organizations); recent publicized attacks demonstrate this. Fame and reputation have always been motivators for hackers but, in recent years, business-savvy blackhats seem to have outnumbered the jesters of the digital underground by a wide margin. Twitter hacks are hardly uncommon and generally seem to be done more for amusement than for any truly nefarious purpose, but they mostly slip by unnoticed aside from a handful of celebrity victims and entertainment reporters. As far as I can tell, the NBC and Fox attacks are no different in terms of motivation, but the side effects are much more serious. Cyber terrorism has been a buzz topic for some time now and, while false news reports may rank relatively low on the impact scale, it is probably only a matter of time before this sort of event occurs specifically in order to incite panic in the general population. That would be a real paradigm shift but I don’t know that we’re there yet. These attacks appear to serve no obvious purpose beyond self-promotion.

It’s long been clear that the US Government is interested in the space and is spending massive amounts of money on information security and new security technology. It’s also apparent that many organizations are waking up to the fact that they need to develop effective information security programs. Recent discussions with clients are generally about how much more budget they will have in 2012 than this year. These are good things and you’d think they’d lead to significant private investment and more innovation that might show up at Black Hat.

However, while Black Hat (and DEF CON for that matter) is supposed to be vendor neutral, you would expect organizations to emerge as industry leaders or at a minimum to show overall industry thought leadership. Other than the US Government and its speakers (in particular Mudge), there wasn’t much commentary on the state of the industry and bigger picture issues. I realize that some of the lack of corporate thought leadership (and momentum) is intentional – Jeff Moss referenced getting back to vendor neutrality in one of the keynote intros and I do understand that Black Hat is more about security research and technology. Nevertheless, in past years, there was at least some industry excitement surrounding new concepts and industry related acquisitions such as IBM buying Ounce and AppScan, or HP buying WebInspect and Fortify. Even the spinoff (and eventual Dell acquisition) of SecureWorks created buzz at Black Hat in the past.  There was really no “buzz” and no real unifying industry vision at this year’s event – which ultimately is important as we mature as a vertical.

As has happened before with the security industry, roll-ups and investment seem to be bungled.  Like the first major round of roll-ups (where Symantec, McAfee, and VeriSign were the acquirers), the latest generation of security rollups appear to be flailing. IBM has struggled to consume ISS and its other recently acquired security product lines. HP appears to be in a similar boat. RSA looked like it might be starting something, but, well they won a pwnie this year…

Don’t get me wrong, I enjoyed many of the presentations – Moxie Marlinspike was great, Nelson Elhage’s preso on breaking KVM was interesting, and I always enjoy the Securosis crew. Additionally, the overall focus on mobile security, IOS and Android was good.  And the open discussion about advanced persistent threat (APT) and what actually is going on with foreign governments (like China) was refreshing – Alex Stamos gave a good 10 minute overview of APT within his presentation comparing Windows and Apple security.

However, you know the industry is having issues when one of the main industry related discussions is about Trustwave trying to go public (which we’ve been hearing for 18 months) and the biggest booth at the show is occupied by a pwnie award winner, RSA (one of the reasons for increased budgets next year). I’m not sure that this will change soon, and, in fact, not having large major players benefits boutique firms like NetSPI, however, with all of the government money and the increased information security budgets, it’s inevitable that we’ll see more investment, new ideas, and new leaders emerge – maybe next year.

Today it’s pretty common to hear people say “we’ve got the network covered; now we’re really interested in pursuing our application security.” In 2006 I remember Charlie Johnson, head of the consulting practice at Symantec, talking about apps being the only thing that mattered and that he was thinking of committing the Symantec consulting team to secure application development. He may have just been thinking out loud, but securing applications has become the focus of many IT security groups almost to the exclusion of focusing on risk to the organization.

Don’t get me wrong, application security is a huge problem and it will remain a problem for many years. However, there are many other areas of risk (perhaps greater risk) that cannot be ignored. At the technical level, system security for off-the-shelf software is a persistent problem. Organizations still struggle to patch quickly and there are often systems with exceptions to the patching process that weaken an organization’s domain and system security. While patching is still an issue, the biggest vulnerabilities are found within network and system configurations. In most (90-95%) of our pen tests we find weak configurations that lead to the complete compromise of an environment. In addition, in many organizations, database groups are silo’d off and don’t get the security attention that they need. Because of this, we find an excessive level of insecure configurations, embedded passwords, and inappropriate trust relationships that can lead to compromise.

With all of these technical vulnerabilities, it’s amazing that an even wider security hole can be found within the physical operations, business process, and personnel at organizations. This is still usually the easiest way to break into an organization. Often it’s combined with technical exploits, but social engineering provides an almost failsafe way to get information and access within technology environments.

I don’t think we should reduce our focus on application security – there’s a lot to do there and it will take many years to secure this aspect of IT within organizations. However, I think it’s incredibly important not to lose sight of what constitutes risk. If you really want to understand and reduce IT related risk, you’ve got to look comprehensively at risk within all aspects of your IT environment – process, physical, network, systems, database, and applications. Because while you may not be looking at these things, it’s certain that at some point, someone looking for the easiest way in will be looking at exploiting these weaknesses.

Being on the forensics team at Ontrack in the mid 1990′s, we saw a significant number of criminal and security related incidents. It truly was the Wild West, with companies moving to Windows 95/NT3.51 before they had a clue about stabilizing them, let alone securing them.  Many people didn’t understand that email lived beyond what you saw on your screen (let alone that files lived on forever on various hard drives). At that time, very few people in corporate America (including those in IT) had any idea about what was going on within their IT environments. In many organizations, the CFO ran IT and no one else at the C-level wanted anything to do with it.  Security wasn’t even a joke for most companies – it was a non-issue, and at Ontrack we got to see that first hand.

That NetSPI started around 9/11 is an unfortunate but good reference point. It was ironic that an event that should’ve heightened corporate America’s focus actually led to decreased attention and reduced budgets for information security. In 2001 almost everyone that I met discussed what a great industry information security must be due to the focus created by 9/11. Nothing could have been further from the truth. Companies were cutting spending dramatically. This wasn’t necessarily the case in the Northeast (because of the proximity of 9/11), but it was around the rest of the country.  IT security was an abstraction unrelated to corporate operations.

From 2001 through 2005 or so, there was lots of commiseration surrounding the lack of traction that information security was attaining.  The “I’m beating my head against a wall” feeling was pretty strong for those in IT security, at least everywhere but in very large financial institutions.  There was always hope that one day people would start to care. In fact, in many conversations there was an underlying sentiment that “the C-level isn’t giving me what I need and some day they’ll pay.” It felt like that someday was probably decades away, but everyone hoped that non-IT and executive management would start to get it.

It’s hard to believe, but I think that day – the upper management getting it day – has come.  Just look at Sony. Because they’re a Japanese company there are some cultural issues that have played into holding the person at the top accountable. It is amazing that there has been discussion about his accountability and the future of his job. It didn’t start entirely with Sony, things have been changing for a while. Events like the RSA breach were a wake-up call and because Art Coviello, RSA’s President, responded, I think we’re seeing a sea change in attitudes and accountability with regards to information security. While the responses and/or the programs are not entirely what many in our industry would consider adequate, we’re seeing C-level responses and there appears to be action behind their words.

At least let’s hope.

What’s scary are the breaches that we are hearing about are occurring at organizations that spend significantly more than average on information security. While each has its issues, the military spends massive amounts on information security and large oil companies tend to allocate security significant budget dollars.  In addition, the breaches at the oil companies were fairly simple: break in through externally available web applications and step through to confidential information and critical processes. Most of the attacks in the McAfee report were based on existing and commonly used tools. If highly profitable companies that spend significant amounts of money on information security are being breached, it shows how massive the problem is that we are facing and how difficult it will be for smaller less profitable organizations to confront.

In the past, when I spoke to what might be considered an ordinary mid-sized business (one that didn’t think it had significant security needs) like manufacturing or healthcare, the response was often “who would want to break into our environment.” Unbelievably, these comments can still be heard within the IT groups of Fortune 500 companies; however, with breaches at organizations like Minneapolis’ Valspar (a Fortune 500 paint manufacturer which had its paint formulas stolen) corporate boards are beginning to understand the risk related to information security within IT and this is one of the keys to addressing the problem.

Corporate boards need to wake up to the massive problem, fund information security, and demand more information about their organization’s posture on a regular basis.  Since boards are usually not made up of IT or security experts, it’s the responsibility of Information Risk, Security, Audit, and IT to provide them with tangible information about security and risk posture.  While boards could ask for the coffee vs. security budget ratio, there are better ways to look at this and budget for this. However, making the point to a non-IT oriented board takes tangible events and understandable facts. As the recent reports and news articles show, the events are happening. It’s up to boards, executive management, IT and information security to understand the facts and plan / fund appropriately.

But what about an attack on a security system that affects the availability of the action of the security controls and/or the availability of the resource that the control is intended to protect? Compromise of data then simply becomes a waiting game for the would-be attacker. This “un-social” engineering attack may include little or no interaction between the attacker and the target. Let us dub it “pressure engineering” or a subset of social engineering.

Imagine a Mr. Mugglesworth working under a tight deadline. At the completion of the work, it must be submitted, transmitted and/or stored in a secure manner. Mugglesworth is as good about following the security procedures as he is about getting his work done on time. Indeed, Mugglesworth is trusted with some of the most sensitive information in the company. But when he tries to submit his work, something is wrong. The security control is not allowing him to proceed. Or the system is not able to accept the work in a secure format. The pressure mounts as the deadline approaches. Mugglesworth is counted upon to complete his work on time, and a missed deadline with “security” as an excuse simply will not do. The temptation to bypass the normal security procedures in order to complete the task is great – especially since the technical or managerial resources are not responsive. (It is after-hours and no one is available to assist.) When the right personnel are available to assist, the deadline will have long passed.

Will Mugglesworth or his superior make an “executive decision” to handle the sensitive information in an insecure manner? Or will they wait it out? The pressure mounts… pressure engineering has been applied.

The answer to this question will depend on the security culture at Mugglesworth’s organization. It may depend on the type of security training and the expected employee response that is cultivated. It may also depend on how the technical issue is escalated and the organizational response.

Where do “Da Rules” fit in at your organization? What would Mr. Mugglesworth do if he worked for you? How would you and your organization address this scenario?

There is no need for a primer on the difference between data and information. It is clear to the users of information that what they want is information. They may ask for data, they may seek so-called data points, but what they are really asking for is information. After all, information is useful; it makes the difference between decisions and informed decisions. And at the end of the day, the information systems people deliver information to decision makers. They store this information in their information bases. No, wait a minute – it is stored in databases. So what they are really working with is data?

Data becomes information when it delivers something meaningful to someone. We can take any block of data and extract from it an endless stream of meaningless information. An example is baseball. From data recorded from each game, we can extract the number of runs scored, the number of bases stolen, the number of games won at home, the number of games won away,  the number of errors made in the last ten years… the list goes on to infinity. Who cares? Well someone at some point may care. Perhaps the real question is “Which was the best team last season?” Or perhaps “Who is the best player of all time?”  Or any other question you could dream up. Regardless of the question, the fact remains that the person recording the plays and the scores at each game does not seek to answer these questions. He/she is simply collecting data and storing it for later use. What will it be used for – 50 years from now? Who knows? Who cares? For some just simply knowing that the players will be back on that field next season is good enough. In the meantime, just let our information people hold on to that data in a safe place so that it’s there when we need it, for whatever reason we might need it .

Now let’s say that some of that data is sensitive. Well, we should protect the sensitive data. Which data is sensitive? (I don’t know – it’s your database, you tell me) The sensitivity of the data will be determined by the sensitivity of the information that will be conveyed when it is accessed. Meanwhile, are you keeping your eye on the ball like a good player? Good – I just stole second base. Are you keeping your eye on second base like a good fan? Good – I just stole your hot dog from under your nose.

Regulation guides us to identify what data is sensitive. PCI DSS tells us to protect cardholder data. HIPAA directs us to protect health and medical information. Upper management decided that your customer list is private and must be protected from the competition. Everything else is not sensitive and need not be protected the same way.

Yet I know of a web-based charity that boasted of impenetrable cardholder data security. Indeed it was. But when credit card accounts were stolen from donors who made charitable contributions to the organization’s website, it was the customer contact list that was stolen, not the credit card database. Why go through all the trouble of hacking a secure database when you can simply telephone the donor and ask for it? They were just as willing to give it out over the phone as they were online.

Information is pulled from an information system. When we know WHAT information will be pulled, and when we know HOW that information is sensitive, then we know the sensitivity of the data from which that information came. If we don’t know the sensitivity of the information or how it might be used, then we don’t know the data. Since it is the job of information systems professionals to store all data holistically, then it is their job of securing all data holistically – not selectively.

As I’ve discussed in the past, the healthcare industry is significantly behind in dealing with IT-related risk.  For an industry to change its approach to information security / risk, its culture needs to evolve. In my opinion, risk is the most effective driver of this change. If the risk is great enough, industries develop a mature understanding of risk management (of which security is a subset). The military and banking have tangible risks tied directly to their IT assets; therefore, they understand risk. The problem is that this mature understanding of risk doesn’t exist in most other industries. Without risk driving a security program, industries must rely on other drivers – usually compliance (also a subset of risk).

What we’re seeing within healthcare is that PCI is driving the maturation of risk. For example, one key issue that keeps coming up, especially in hospitals, is the belief that PHI is more important than PCI / credit card information. Yet it is PCI compliance that has forced organizations to think systematically about risk. How do you reconcile the budget for PCI compliance with the lack of budget for PHI-related security?

In addition, PCI has forced multiple groups (including IT, security, audit, and finance) to work together to deal with compliance and, ultimately, information security issues. Many of these same groups are now being asked to deal with HITECH / ARRA / updated HIPAA.  With the new interpretations of HIPAA, the new regulations, and with these new sets of eyes, these groups are beginning to understand that they are not compliant with HIPAA, that they have significant risk exposure, and that they need to develop programs to deal with this exposure. 

From what we are seeing with many of our healthcare clients, the combination of a more pervasive awareness of PCI and new healthcare-specific regulations are creating a more mature understanding of risk and driving a new focus on developing successful information security programs. Let’s hope this trend continues.

On this topic, Rich Mogull had a very good presentation, “Putting the Fun in Dysfunctional,” about the inherent problems with information security. I appreciate insights from someone with both an IT and a physical security background and I thought he did a nice job discussing why security is such a difficult area for a business to understand.  I agree with the points he made that at the most simple level security and risk are abstract, long-term concepts that require a rational approach.  Rich did a good (and entertaining) job of illustrating that, as humans, we are often not rational. Generally we deal in the short-term and prioritize with our basic needs. In the context of a corporate environment, understanding and dealing with risk is extremely difficult.  

I’d add to Rich’s discussion that in most organizations building mature risk management is essentially like playing a game of telephone across functional departments, most of which find risk and security to be totally foreign concepts (except, of course, at financial institutions).

Rich’s thesis created a nice framework for the other core topics at the conference. A number of presentations dealt with the dangers of cloud computing. Because we created the cloud without rationally dealing with risk and security, it’s an afterthought; there are huge holes in cloud computing security and therefore significant risk.  David Bryan had a great presentation on the subject.

The other core topic, PCI, is generally thought of as a compliance issue.  Anton Chuvakin put some context around PCI and how it fits as a basis for a security program.  I’ve seen a number of organizations do this, and Anton did a nice job outlining the gaps related to using the standard as a basis. While no standard is ideal, it’s a start and generally kick starts a maturation of risk management within organizations that adopt the approach.

Overall, the Secure360 conference was very good and the speakers both local and national were great.  Kudos to the organizers. I look forward to next year.

First, the insight that only 2% of organizations fail their PCI audits should raise some eyebrows. Taking it at face value (and there’s certainly room for discussion about that) it indicates that, in general, retailers and payment processing related organizations are taking PCI compliance seriously. However, when combined with another observation in the report, that about 40% of organizations are relying on compensating controls, it illustrates the subjectivity of the standard and of the “auditing” process.  There are a number of other conclusions that can be drawn from this high pass rate, and hopefully, the Council will look into them.

Second, the report says that over 50% of the QSAs surveyed observe that information security is still not being taken seriously by the organizations they are auditing.  Even though almost all of the organizations covered in the review are addressing PCI, most are not truly addressing security and, by extension, risk – which is a level of maturity that usually requires enlightened management or a breach.  This finding further highlights how important it is for audits to be done by competent and honest auditors.  Like the point above, this gets at the core of PCI – the standard and the associated subjectivity should evolve to ensure that security and risk be addressed, not just compliance.

Finally, the report states that QSAs feel that firewalls and encryption are the most effective technologies used to protect cardholder data. The number of organizations that think they are doing one thing (with technology) and are actually doing another is amazing. ASV scanning is a very important component of verifying technical compliance, but with self-attestation for many internal components it doesn’t cover nearly enough. With this in mind, the PCI Council should implement further verification to ensure that technology and controls are implemented properly. This would continue to drive the convergence of compliance and security. More reviews – especially third-party – would also help organizations better understand risk and develop mechanisms to mitigate it programmatically.

Overall, the report says as much about the state of the PCI standard as it does about the organizations it covers. Some of the more interesting insights are the implications surrounding PCI’s subjectivity and maturity.  The positive take away from the report is that it appears organizations affected by the initial PCI focus (retailers and payment processing-related firms) are taking PCI compliance seriously. To achieve the common goal of reducing IT risk related to PCI data, hopefully the Council will be able use this report  (and other similar reports) to enhance the standard to cover more security and risk.