The security safeguards that we can put in place can be administrative, physical, or logical … (I use the acronym APL to help me remember this … like the old programming language!!).

Administrative – policy, standards, guidelines, process and procedures with training and awareness (the people part of security);
Physical – facilities, locks, secure areas, badge readers, guards;
Logical – the technology, electronic systems, computers, USB sticks, networks.

I’ve always felt that the best way to IT Security is through Information Security; you (the techies) are forced to understand the business needs and then IT isn’t viewed as “forcing security down our throats”.

When you say;

“There’s no iteration of protect the data that could have possibly worked here. ….in order to be usable, the data is always going to have to be in a vulnerable, unencrypted state at some point”

I would like to provide you with information for future consideration.

Trustifier technology provides file level access control by digital separation of access privileges by authorized users at the OS kernel level.

As you say, much data escapes the enterprise, either accidentally or intentionally, when it is in its unencrypted clear-text state being manipulated by the user with access. Trustifier enforces the rules that govern what can and cannot be done by the user, to any data, protecting sensitive information from either internal or external abuse, even in an unencrypted state.

Trustifier’s additional controls allow it to be viewed as a protector of data in use, and as such, another layer of protection, and a much needed one according to your quote.

There is also a good chance that with its mandatory access controls and sub-app level monitoring, Trustifier could have prevented Heartland from its breach in one of two ways. Depending on the attack plane of the malware and systems involved, the malware may have been prevented from owning the server(s) in the first place, due to its mandatory access controls and whitelist functionality at the system call level. The malware’s attempt to load itself may have been denied. Alternatively, by creating least privilege access rules (as Ron Lepofsky suggests) that are based on the business operational rules, the malware would have not been allowed to execute and send its payload home, if it was violating a business rule (which it obviously was).

@Khurt,

I think a better picture to paint is one of networks comprised of inherently secure computers as opposed to networks full of inherently insecure ones. Then one might have to deal with less network crap.

Part of the reason we have ‘network crap’ is because we’ve done such a bad job of clearly defining the tools we want to use to protect the network and just accepted what the vendors have fed us. But to your “magic soda formula” point, too often we as security professionals don’t even know what pieces of information are that formula and what’s just data.

One of the things I love about being a QSA is that I get to see so many systems and experience the drek as well as the gold nuggets. The people I’ve seen who are most successful acknowledge that the data is what they’re trying to protect and build the network around it to be as secure as possible. The ones who are least successful are the ones who throw a bunch of tools at the data hoping one of them will catch a bad guy if he shows up.

Richard is well known for his ideas on exfiltration. He concentrates on what’s leaving the network. He does a very good job of it, but he’d be the very first to admit that his expertise is just one more layer of protection. What’s got him (and me, to a lesser degree) up in arms is the thought that we can ignore those network protections and “just protect the data”. The two are intertwined and will continue to be.

Martin

In our experience, many companies, even medium sized, with only a few hundred employees, do not rigorously implement the basics in privilege management. I suggest all companies, with special emphasis on electronic transaction processors, create, implement, and rigorously enforce the management of users, privileges, and separation of duties in order to enforce appropriate privileges.

Particular attention needs to be paid to third party users and their privileges. Two roles should be created in order to achieve success with this process: one individual to create/delete/monitor user names and privileges in a very timely basis, including auto deletion based upon pre-determined times; one individual or group with sufficient separation of duties to impartially verify the process.

Ron Lepofsky, B.A. SC. (Mech Eng), CISSP
http://www.ere-security.com

Seats belts, air bags, anti-lock brakes, traction control, crumple zones, guard rails, and the road surface are all designed to minimize risks to the valuable contents of the cars. None of it is designed to protect itself.