Let us turn to “Social Engineering” for a moment. The first thought for many of us is the writings of Kevin Mitnick (The Art of Deception and The Art of Intrusion, co-authored with William L. Simon) that used real-life and hypothetical stories to demonstrate how social engineering can be combined with hacking to bypass technical security controls. We think of the call to the help desk in the middle of the night to unlock the executive account, and the psychological pressure exerted by the attacker implying retribution if the task is not carried out immediately. Or perhaps a rogue website that is accessed through a series of phishing emails that in turn collect sensitive information.
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?
A dichotomy exists between information and data – and the way that information and data are discussed, stored, protected, and used. Any number of people reading this might identify themselves as working with “Information Systems” in the field of “Information Technology,” and some of them work with “Information Security.” Sometimes they attend meetings and talk about “Information” and “Information Sharing.” But most often they are talking about “data” – data flows, data stores, data shares, data systems, data access, data security, and so on.
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.
I like to watch industries evolve in how they deal with information security. It was interesting to watch retail evolve as PCI got more organized. The PCI Council put together the DSS with dates and penalties for breaches and non-compliance, and that drove significant change. It appears that a similar major change within healthcare is starting to take place. We have begun to see a proactive shift that incorporates compliance with HIPAA, an understanding of risk, and the development of security programs.
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.
We held the Secure360 conference in the Twin Cities last week. Presentation topics included PCI, cloud computing, and problems within the security industry. While it can get tiring discussing the industry’s problems, I like trying to understand the difficult nature of information security and enjoy the challenge of trying to overcome the obstacles related to rationally dealing with risk.
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.
In late March Thales released an interesting report on the state of PCI – “PCI DSS Trends 2010: QSA Insights Report.” The report was written by the Ponemon Institute and it highlights the difficulty of taking into account risk, security and subjectivity within the PCI DSS compliance standard. If you haven’t read it, here’s a link: http://iss.thalesgroup.com/l/program/pcitrendsreport.aspx.
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.
Subscribe to Security Industry Blog
