The Security Blog

Evolution of Defense in Depth

As security professionals will tell you, one of the basic principles of a good security program is the concept of Defense in Depth.  Defense in Depth is arguably the most time-tested principle in Security, and applies to physical security, as well as information security.  Defense in Depth builds on a concept of a hardened “core”, where one places their “crown jewels”.  This core is then surrounded by castle walls and motes, with ever increasing generality of defense.

Defense in Depth is a great concept, but it comes at a price.  Just as the area covered is wider from layer to layer, so is the cost associated with protecting with against more plentiful and less and less specific threats.  A firewall, for example, that typically acts as the last line of defense on the enterprise perimeter, has to protect against a great many varieties of threats, while a server-room door has to “only” be concerned with physical access.

The Server Room in The Center of The Castle

Another flaw in the Defense in Depth design is its inherent difficulty to implement vis-à-vis the three basic tenets of security: Confidentiality, Integrity and Availability.   Why?   Because most forms of defense create increasing Confidentiality, but make Integrity more difficult to implement and manage.  Any increase in defense, of course, makes the concept of Availability that much harder to provide to the users.

A difficulty that I myself encountered many times is the applicability of Defense in Depth to my “layer 8” problem – the users. If users are not trained properly, if they are not aware of information protection needs, methods, and the “why?” of it, they become a liability, rather than an asset, towards data security.  If you are like me, you find the need to increase our moat-to-user-ratio on an ongoing base harder to design, implement, manage, and pay for.   Many of us resign ourselves to the proverbial “this is reality” and define our demarcation line as a physical device, such as a router, an access point, a firewall or a webserver.  There are potentially two things “wrong” with doing so:

1. We are basically saying  “we are a target just waiting to be attacked” and
2. We allow most barbarians (in the form of rogue traffic, networks and devices) to hit our gates

If we continue to do so, we will have approached a mathematical certainty of being hacked, or at least DDoS’ed out of the Net.   I really prefer NOT to draw analogies here to the real world, and we all know which those are.

Not only is the problem above big enough to cause some to lose sleep, but imagine what happens when we move to a Cloud topology… there we have nothing but moats and walls and front doors.   These front doors can be any browser, on any device, anywhere in the world.   How do you protect yourself against that?   Speaking of losing sleep – I love coffee, but this is ridiculous.

Clouds, Doors, and Windows. Source: desktopnexus.com (Heavily edited)

Like any solution that might involve our entire user set, which may include Internet users, rather than pure corporate users, any solution must be:

1. Easy to teach (i.e. close-to-zero learning curve)
2. Easy to implement
3. Applicable to the widest range of platforms possible
4. Have a small delivery and storage footprint
5. Easy to manage and maintain

Not asking for much, am I? 

Knowing how rapidly threats involve “in the wild”, I also want a tool that does not go the normal route of “black listing”.  I am more and more convinced that we need tools, in our world of security, that no longer compare bad signatures or behavior to a database (which is how most antivirus and firewalls, for example, act) and we need to go the “white-list” route.   I will write about that in the future.   Yes, I want a tool that will be controlled by me and allow me to choose which domains can be accessed, and under what (time or other) conditions can such an access occur.  Let’s add those to my “dream list”:

6. White list based
7. Conditional access

To make matters even more interesting, I want control over certain user functions.  (We want, after all, to reduce the number of barbarians and the number of roads leading to our castle, don’t we?)  We want to make sure that the people that request a resource are authorized to even request it.

For example, I would like some files to be able to be read and written, but not printed.  Or that I be able to control launching certain tools, such as IM or browsers from within the session.   And finally (?) I want a bullet proof audit trail.  Why?  SoX, GLBA and HIPAA, to name but a few.

8. Selective access to file functions
9. Audit trail

What should we do?

Until now, I did not see any solution to this quandary.  Other than Awareness and Training, there was not a whole lot that could be done.   Even MSSPs would tell you – they are there for a reason, which is “people will attack you”.

Thanks to my friend Andreas Wuchner, the CISO of Novartis, I ran (head first, mind you!) into a newly launched company called Quaresso.  Launched by a group of smart people with backgrounds in networking and security, in “Protect OnQ” they created both a new product and a service.  Working together, these allow us to do a few things:

• Firstly, they allow us, the people responsible for the data’s protection, to select who will be allowed to knock on our doors and with what.  Simply put, if you so choose, people without the proper tool will not even be allowed access to your castle.  “Not allowed on the island”, if you would.  And this permission is manageable in real time.
• Then, you can select not only which browser is allowed to knock at your door, but also to choose what (and what NOT) that browser is allowed to contain: add-ins, plug-ins, encryption settings, printing ability (or not), security zone setting, and the list goes on.  This effectively extends the defense-in-depth to the actual browser session!!
• If this was not enough, you are able to control THE ROUTE that your users take to reach you.  While it may seem either unimportant or even impossible, controlling a browser’s allowed connections has the ability to protect against man-in-the-middle attacks, to name just one example.  To prevent DNS hijacking and man-in-the-middle attacks, the knowledge and selection of the route is also critical.
• Zero-day (zero minute, really) malware protection – if it is not known, it does not get transported.  Simple and neat! 
• And the final cherry on the icing?  Remember all those virii, trojans, key loggers and co.?  Due to the implementation of the “armored” browser, data can no longer leak from it to the rest of the operating system.   All passwords and personal information typed into a protected browser session remains confidential and un-recordable.   I know I will sleep better.

I tested the tool in several scenarios.    The only drawback seems the need to install another icon on the users’ screen.  I particularly loved it when, while running the tool, I had a sniffer on and could sense no data passing from the browser unencrypted.  So much for data leakage via this route!

So…. Let’s compare this tool to my wish list.

The tool does all of these, while requiring zero learning curve to the users.  By allowing the users to use the same browser they are used to and by clicking as they normally would.   No new software, no new directions, nothing.   We now protect another layer of Defense in Depth and greatly increased our control of who comes knocking at our doors.

Try it and let me know what you think.  

This article is my first in the series which I called "Clearing the Clouds" talking about security and Cloud computing.

Here it is, as published on May 19, 2009, on CSOOnline.com

In Depth

Cloud Security: Danger (and Opportunity) Ahead

In the first in his series of "Clearing the Cloud" columns, security expert Ariel Silverstone explores the dangers of cloud computing and outlines security best practices to make it work.

By Ariel Silverstone, CISSP

The dramatic change in the rate of adoption and the amount of discussion taking place regarding cloud computing demands that this technology, or rather a set of related technologies, continue to evolve utilizing a security-sensitive design.

We approach quickly the point in which the amount of data and of processing in the cloud will be not only unmanageable but also pose a security and related privacy risk to the users of the data, and to people who the data concerns. [Cisco CEO: Cloud Computing a 'Security Nightmare']

In this series of articles, I do not intend to solve the problem of security in the cloud. My intent is to define the problem and propose several salient ways to address it. As always, comments are welcome. [Related: Cloud Computing: Making the Right Choices]

Terminology

While the term "cloud computing" may be new, the idea certainly is not. Just look at the greatly varying definitions I found while researching this article. These include all of the following technologies:

• 1. The grid
• 2. VMWare and Xen-type virtual machines
• 3. IBM-type mainframes
• 4. Amazon-type flexible storage
• 5. Intel VTX-type hypervisors
• 6. Page files
• And many, many others

Instead of focusing on a specific technology, I propose we define the salient characteristics of cloud computing. For the purposes of this article series, I will define cloud computing as the technology having the characteristics of:

"Service-based data processing and storage capability which is flexible, extensible and virtual"

Some may add the following:

"and available via the Internet"

I will treat the second part of the definition as optional, for the purpose of discussing security. I find that the connectivity method here is secondary to the basic tenets of security, and thus am able to include locally virtualized machines in the discussion.

Generally, the purpose of cloud computing is to avoid the expense involved in building or acquiring the infrastructure. Similarly, when deploying virtual machines, one does not buy multiple servers or separate processors. I find the computing slice concept — which includes storage, processing power, etc. — to be a compelling one. In the near future, I predict that we will not even CARE whether the computing slice resides locally or across the world. As long as the computing service is provided in a timely and efficient manner, we will be satisfied.

When dealing with cloud-based delivery, the problem with security grows. Instead of having direct control over our concept of "defense in depth," we now have marginal control at best. Many times, such as with Amazon's EC2 service we have virtually no control, no pun intended. We sometimes do not have even the basic notification of something about to go wrong or something that has.

Both for Amazon's service and for our basic hypervisors, we no longer control ingress to the machine processing space. In the case of Amazon, it is Amazon's routers (and presumably firewalls). In the case of our virtual machine managers, we relegated the inter-memory systems and processes to the handling of a "black box," one that we seldom, if ever, have any control over. These are security problems and I also believe that these are legal problems. Allow me to explain.

What happens if and when data that we store or process on a virtualized machine gets compromised? Will we know? If WE do not know, how will we notify our constituents, especially when data breach notification laws are in place? How will we know to improve our security?

These are not idle words. If you look at the Amazon contract (and this is an example only, I do not wish to "pick on" Amazon, which I appreciate and respect), you will see the following sentences:

"4.3: We are not responsible for any unauthorized access to, alteration of, or the deletion, destruction, damage, loss or failure to store any of, Your Content (as defined in Section 10.2), your Applications, or other data which you submit or use in connection with your account or the Services."

"7.2: We will have no liability to you for any unauthorized access or use, corruption, deletion, destruction or loss of any of Your Content or Applications."

What you do not see is that the provider accepts any responsibility or duty to inform the data owner, you, of any breach, notify you of any attempt, nor responds to any incident. The agreements are worded such that the customers' of Cloud computing bear all responsibility for such risks. It therefore appears that any law requiring breach notification, and any regulation or requirement, such as PCI, cannot be complied with.

Since the concern above is present, and understanding the incredible potential of cloud computing to improve the performance of IT foundation and infrastructure, we must find a solution, or a set of solutions, to standardize and address security concerns communicating to the cloud, within the cloud, and to data elements which reside therein.

In the next article, I will discuss the requirements for such solutions, and will include the excellent proposals brought forth from the Jericho Group and from the Cloud Security Alliance. I will also issue a "call to action" for these and other organizations to address the issue of cloud security before the technology become either unmanageable or, conversely, be seen as too risk-laden for corporations to use.

Ariel Silverstone is a veteran of the Israeli Defense Forces with experience in physical and information security and regularly contributes to information technology certification exams and to newspapers, magazines and electronic publications while working on a Radio show. He holds both the CISSP (for security) and the CBCP (for business continuity planning) certifications, as well as many others. During his IT and management consulting career, he focused on providing IT strategy, engineering, and assimilation solutions for a portfolio of primarily Fortune 500 clients, including USAA, Chase Manhattan, Citibank, GTE, General Motors, Ford Motor Company, Vanguard Funds and others. He specializes in companies in the financial services, transportation, medical services and high-tech industries. He has also been a director at Symantec Corp. and CISO for Temple University and for Bell Canada's Teleglobe.

 Permalink