Why Compliance Can't Create Security'Security Poverty Line' Erects Barrier for Smaller Organizations
When budgets are tight, security often suffers. Complying with regulatory mandates does not always equal security. Yet, many organizations spend budgets meeting standards to which they can rarely without adequately address security and informational risks.
What steps can smaller organizations and the vendors with which they work take to ensure security is not overlooked? They must transcend what Wendy Nather calls the Security Poverty Line.
Organizations that can't afford to implement adequate security fall below that line because they spend too much time trying to meet out-of-reach compliance requirements, says Nather, research director at 451 Research, a technology analysis firm that focuses on IT and security. "That isn't necessarily efficacious," Nather says in an interview with BankInfoSecurity's Tracy Kitten [transcript below].
The Federal Financial Institutions Examination Council's updated authentication guidance is one example. "Even with the online authentication guidance, if an entity doesn't have the wherewithal, the in-house human resources or the technology to comply with those requirements, they're not going to be able to achieve it," she says. "What we really need is something to help these smaller organizations and even larger organizations figure out on a day-to-day basis how to adapt and how to manage additional risk.
One suggestion: Develop IT- and security-focused community groups for the exchange of ideas, information and known security threats. "In the financial sector, [that would be] where information security officers can come together and discuss problems," Nather says. More broadly based local groups could instead encourage information-sharing among any sort of business or entity.
Another suggestion: More outsourcing to managed security-services providers. Vendors that specialize in security enhancement and compliance are emerging to tackle issues in specific vertical markets. "These providers are working very hard to lower the price point so that these entities can start using them," she says.
During this interview, Nather discusses:
- Why internal education that focuses on security and risk is the only way to truly address fraud;
- How value-added resellers can play increasing roles in security and risk mitigation; and
- Why vendors specializing in managed security services will soon need to address the requirements of small-budget organizations.
Nather has more than 20 years of IT experience both in the public and private sectors. She joined 451 Research, formerly The 451 Group, after building and managing all aspects of the IT security program at the Texas Education Agency, where she directed multimillion-dollar initiatives for a statewide external user base of more than 50,000. She also provided security guidance for the datacenter consolidation of 27 Texas state agencies, participated in major state procurement evaluations and contributed analysis for new security legislation. Nather previously worked in various roles in the investment banking division of Swiss Bank Corp. [now UBS], including helping to build Europe's then-largest private trading floor. Based in Chicago, Zurich and London, she also served as the first IT security director for the EMEA region, managing the security aspects of various mergers, IT operations outsourcing and the division's first Internet presence.
Struggling with Ongoing Security
TRACY KITTEN: Why are smaller organizations expected to struggle more and more with ongoing security and fraud prevention?
WENDY NATHER: Well, there are a couple of problems. First of all, there's what I call the Security Poverty Line, where if you don't have enough money, even for IT, obviously your security is going to suffer as well in a lot of different ways. You won't have the expertise on-site that you need for ongoing investments in security. You can't go out and buy everything. And the other problem is that there's really no finish line for security. Even if you come in with a bunch of money and say, "I'm going to buy everything I need to meet this mandate or to establish this level of security," there's no shopping list. You can't go and know that you're done buying what you need and executing on the program that you need. It's sort of a moving target and it's very difficult to fund if you're a smaller merchant or a smaller entity.
'Security Poverty Line'
KITTEN: As time goes on, vulnerabilities are expected to greaten. You've proven this through the system or formula that you just talked about, the Security Poverty Line. Can you explain what the Security Poverty Line is and why it proves that security will always be out of reach?
NATHER: The Security Poverty Line, as I mentioned before, most often refers to companies that simply don't have enough funding for IT, or even for security, to be able to do security well. This ends up with a lot of syndromes. For example, a company that doesn't have a lot of money for servers is going to consolidate as many functions as they can on the same server, and this conflicts directly with the basic rule of separation of duties, which you need to prevent fraud and to prevent other security problems. I have seen, for example, breaches happen where a company simply had too much on one server, exposed to the Internet, there was a configuration problem on the site and data got out. That's one example of where the Security Poverty Line can affect a company even trying to put in baseline security.
The other problem, as I mentioned, is that it's a moving target. There's a blog post I really like by Josh Corman, who used to be a research director at 451 Research, where he referred to something he called HD Moore's Law and this is kind of a tongue-in-cheek reference to HD Moore, who is the creator of Metasploit, which is an open-source penetration-testing platform. Basically, his point is that the level of effective security that we need keeps moving, that it moves at the rate of Metasploit, or any other open or easily available set of pen-testing tools. An attacker, even a casual attacker, has more power available to them every time a new exploit comes out in one of these tool kits, and defenders have to respond by being able to adapt to that set of exploits.
That just moves too fast for most organizations to keep up with, even ones that are well-funded; and ones that aren't well funded just can't keep up at all. The problem is that, if you're trying to aim for a regulatory mandate such as PCI, it doesn't take this law into effect. It's not updating the baseline level of security as new exploits come out and as the power of the casual attacker grows.
KITTEN: And you've probably answered my next question, which is where and how is the industry approaching security from the wrong perspective? I think we talk about this quite often. It's not just about compliance; it's about ensuring security, because compliance, or the compliance mandates, will never be able to keep up with emerging threats that are hitting us every day, every hour.
NATHER: Yeah, exactly. And to be fair, those who are coming up with these regulatory standards are doing the best they can. These sort of things that have to fit all or have to fit a certain level of assumed risk across an industry take a long time to put together, and they're just not as accessible as an individual chief information security officer making day-to-day risk decisions and acting on them. You can't really expect a mandate to keep up with something as dynamic as HD Moore's Law. You really need something better to put into the hands of individual security officers to adapt even outside of the regulatory requirements.
Keeping up with Compliance Mandates
KITTEN: I'd like to ask you, if smaller organizations will never be able to keep up with these security mandates, such as the PCI Data Security Standard that you mentioned earlier, then what does that say to us about the efficacy of industry mandates and standards overall?
NATHER: Well, it's a really tough problem to solve. First of all, there's keeping up with the mandates, and the mandates assume a particular level of security risk across the board for a given function. For example, for PCI, it assumes that anyone who processes card payment data has this general, same level of risk regardless of how big or how small they are and regardless of what concepts they're using to process that payment, regardless of what kind of infrastructure they have, and so on. It's mandating a certain level of activity and risk management, and that isn't necessarily efficacious. That's not necessarily what any given individual organization needs to protect against an attacker.
It's very hard for a regulatory mandate to keep up with a dynamic environment like this, so we really need two separate activities for any merchant. One is to achieve what really works for them in terms of lowering their security risk, and then also matching what the regulation assumes is their level of risk, and those are two different things. Merchants still have to go above and beyond meeting what's on their checklist for their audit.
Now, the problem is that a checklist is a lot easier to accomplish and you know when you're done. And for security efficacy, there's no checklist and there's no way of knowing when you're done. That's why a lot of merchants tend to stop when the checklist stops and they don't know where to go from there. Even if they know they need to do more, they don't know what that "more" is.
Addressing Security 'Hollowness'
KITTEN: That's a great point and it kind of ties into the next question that I wanted to ask. Who should be charged with addressing the seeming hollowness of some of the industry mandates and standards that are now being required? If merchants need more clarification or they need to have assistance, what agencies will help them do that?
NATHER: That's a great expression, the seeming hollowness of some of the mandates. Again, I think those who are doing the mandates are doing the best they can, but it's simply the wrong model for keeping up. What we really need is something to help these smaller organizations and even larger organizations figure out on a day-to-day basis how to adapt and how to manage the additional risk. And I gave a talk on this at Rapid7's UNITED Security Summit a few months ago, and somebody in the audience came up with a great point, that in order to address shared risk you may need to form community groups that are exchanging ideas, not just within, for example, the financial sector where information security officers can come together and discuss problems, but more broadly-based local groups that can help any sort of business or entity address their security problems. And a cooperative model might be something that we could try.
KITTEN: Now, does the Security Poverty Line formula apply to all types of security mandates, such as mandates financial institutions are now facing for conformance with the FFIEC's updated online authentication guidance?
NATHER: I believe so. First of all, the poverty line is there whenever there isn't enough money to do something, regardless of what they're trying to do or for what reason, whether it's for a mandate or whether they're trying to achieve effective security. So even with the online authentication guidance, if an entity doesn't have the wherewithal, the in-house human resources or the technology to comply with those online authentication requirements, it doesn't really matter what the guidance is, they're not going to be able to achieve it.
Improvements for Smaller Organizations
KITTEN: And what advice could you offer to regulators and other bodies such as the PCI Security Standards Council? Where can improvements be made to help these smaller organizations maintain security?
NATHER: Well, boy, how long is this podcast going to be? That could take a really long time to answer. I think that not only giving guidance in a very generic form that somebody has to be able to read and understand and be able to implement but perhaps working cooperatively with the security community to actually work hand-in-hand with these merchants and with these entities to help them day-to-day. For example ... resellers tend to know a lot about these smaller entities because they work with them all the time and they support them directly. These might be useful channels to help establish better security lines that do follow the regulatory guidance, that they take the end organization a lot farther than they do today.
KITTEN: And what about advice for financial institutions and other businesses or organizations that are struggling to keep up with security mandates? What advice could you offer those entities?
NATHER: One of those areas where we're seeing a lot of improvement in security is actually through third-party services, managed security services. There are a lot of providers out there that are starting to specialize in different verticals, like healthcare or financial institutions or very large, dispersed global organizations. These managed security providers are actually sort of an all-in-one shop that has the expertise that these companies could use. It's a matter of being able to afford them, of course, but these providers are also working very hard to lower the price point so that these entities can start using them. Moving a lot of those security functions to an MSSP may be the right answer for some of these smaller organizations.
KITTEN: Before we wrap up, what final thoughts would you like to leave our audience with generally as it relates to the Security Poverty Line or compliance overall?
NATHER: I think the problem that we have in general in the security community is we only see the most vocal entities and the most active ones. The ones that can afford to send people to security conferences, for example, or the companies that have the most expertise, those people take part in the security discussion at large. There's a large silent majority out there of companies as small as your dentist's office for example that take credit-card payments that are struggling to adapt, even assuming that they're trying at all. There's a large group out there that's struggling to deal with these security problems. They're not really getting the voice that they need, and I think as a security community we need to try to focus more on helping them solve those problems.