To Stay Ahead of New Threats, We Have to Keep Developing New Ways to Look at Security that We Haven't Considered.
Some people may say challenge authority, or challenge "the man". The Occupy Movement caught our attention not so much because of the message itself as much as the means - the widespread, grassroots rebellion against the status quo. The amount of information passed to WikiLeaks and the numbers of other hacktivist movements speaks volumes of the dissatisfaction that exists with the general status quo in society. People want change, and sometimes they are so eager for change that they don't always consider if they are serving as an impetus for change for good, or just for change.
Information security hates change. Loathes change. The more things stay the same, the easier they are to control. Patches have flaws that need to be fixed. New operating systems include new bugs. New applications include vulnerabilities. New utilities or plug-ins have vulnerabilities. Sometimes they are new vulnerabilities, and sometimes they are updated versions of old vulnerabilities, but they bring pain. New technology brings new avenues of threat. You can certainly appreciate that an organization which runs hard-wired client terminals off a mainframe, has no web presence, and no wireless, is probably generally more secure than your typical web-enabled company.
The true purpose of security, after all, is NOT to say "no", but to make sure you can say "yes" in a secure manner. A manner that protects you, your staff, your organizational assets, your organizational information, your client information, your stockholders' investment and potential future income. That is why an organization evolves, and security must evolve with it - to enable itself.
Typical IT-based implementation plans are not as effective as they use to be. When we added a new technology, we use to talk about ROI, ongoing maintenance costs, and maybe, just maybe, disaster recovery. Today's world truly is more complicated. Now we have to consider the complexity that the new technology will add to the security of our environment, along with any compliance requirements that may be placed on any data upon which the new technology will rely.
Will the new technology change the way we communicate? Does it mean we will need an external connection to the outside world? Can this connection be encrypted? Is it web enabled? Does access require a client installation? Does it need to support internal staff only, or public access as well?
Will the new technology change the way we store data? Is the data more or less sensitive than other data we use within our environment? Does the system provide an inherent encryption? Is it real encryption or some form of scramble, obfuscation, or "proprietary encryption"? Can I store the data in my existing database or do I need something new - either a new db or a dedicated set of tables and/or db instantiation?
Will the new technology change my regulatory requirements? Does it add or change my PCI, PHI, or other compliance requirements? Is it a new classification of data that I have not previously used or supported? Does the application or technology support my needs for access control to meet regulatory requirement for protection of compliance data? Or my logging/audit needs? Does the application directly support compliance reporting, or do I need additional support?
Will the new technology require changes to my operational controls to either support or compensate for organizational impact? Will I need to update my security policy and organizational training? Will I need to update my organizational insurance to help cover any additional potential risks that I cannot otherwise mitigate?
Will it work with my existing technology and support infrastructure? Will it run on my existing platforms, or if I am a Windows shop am I suddenly looking at a linux server? Does it want a client/server architecture while I run a distributed operation? Does it require a web-enabled infrastructure while I support a more traditional (or "old-school" depending on your point of view) architecture? Does my current architecture support it or am I going to have to rebuild my internal network just to make it work?
These are really only some of the questions we should be asking, but they are in the right direction. The question of "do I need to buy another server?" is much easier to answer than "exactly how does this change my risk profile?" But, we need to make sure we are asking, and answering, the second question.
The more difficult part of this is answering the challenge of thinking differently about what we do. Hackers and criminals are constantly thinking up new attacks, new attack vectors, new ways to circumvent the security controls we have in place. Conventional security methods have gone a long way towards securing our environments. When implemented correctly, security in depth, or layered security measures, provide controls that reinforce each other. In a perfect world, this should mean that one layer can make up for a flaw in another layer, so a systemic failure would be needed to result in a full compromise, and oddly enough, this is what we see in most successful, big attacks - not just a failure of a single point, but one or more weaknesses that together allow more widespread compromise. The "bad guy" is, just so you know, asking those questions - and thinking outside of the box.
A. Think about the organization that has a world-class Internet presence, with layered firewalls, and segregated networks. They control their web presence, and limit enabled functions to well-tested applications which run on hardened servers and are protected by application firewalls. They are effectively as unhackable as they can make themselves. At least, until some guy climbs over the wall that surrounds the outdoor lunch area and walks into their corporate headquarters through an unsecured door then drops a wireless access point on the network in an unsecured internal training room.
B. Think about another organization with a similar web presence, hard-wired dedicated workstations with firmware that limits available functions. Their only potential entry point is a web-accessible printer that is used to print local receipts. Until some guy hacks into the printer, roots it, compromises both internal network stacks, and launches successfully attacks into the organizational network, through a printer. And, while he is at it, changes the printer setup to include "Thank you from the Dark Lord of the Sith" on the receipt.
C. Think about another organization who functionally has no web-presence other than their one server that only accepts authorized SSL connections. Everything else they do is hidden behind their SSL server. Until two guys rewrite all of their hacking tools to work through SSL, on the fly, and within 24 hours are pulling data from the servers in the organization's internal network.
New stuff. Cool stuff. Thinking out of the box. Well, "cool" yeah, as long as the organizations being broken in these manners are clients and these are paid engagements - and they were. Thinking out of the box? I would say so - at least "out of the box" in the security context of each individual client. The attacks worked exactly because the clients never even thought of those avenues of attack at all. It is hard to defend against something you could not even conceive.
New? Hmm. For "A", I scaled that wall in 2004. "B" was 1998, and "C" was 2000. So, not really new, though many attacks are potentially new to the victim, especially if they do not have a different way of looking at the problem.
And the point is that thinking "differently" was, and is, important. You cannot let your security become boring and predictable. Admittedly, some "predictable" is good, if it is predictable in the way it supports you, and the way you support it. But your security cannot be common, cannot be routine to the point that it is predictable. To stay ahead of the new threats, the developing threat vectors, we have to keep developing new ways to look at security that we have not considered. New controls, new techniques and new technology. Security evolves, so to be truly effective, organizations will have to be as effective at developing countermeasures as hackers are at developing exploits.
Don't just think "outside of the box". Challenge common perceptions and be creative. Look at it more this way - there is no box.
Related Reading: Security Strategy? What Strategy?