Is Increasing Abstraction Helping or Hurting Security

It's been years since I have had to make firewall ACL changes.  Now when I work with my HPCloud.com public IaaS instance, I still care about firewalling and limiting access to my virtual machine, but I don't log into the Provider-1 interface, or make command-line ACL changes anymore ... primarily because that has largely been abstracted away from me by the tooling behind the user interface.  This got me thinking ... even though we've discussed this a bit in the past (primarily because I've seen the blog posts and colleagues conversing on Twitter) I think the issue needs more of a spotlight for the general public.

 

I've started to think about the impact that abstraction (in the cloud context) is having on security and risk profiles of organizations.

 

On the one hand, because you're having the difficult work done for you behind the scenes and don't have to think about details, automation may actually increase the likelihood of doing security right.  On the other, because you don't really know what's going on don't have direct knowledge of the details of the changes being made.  It's an interesting viewpoint to look from, don't you think?

 

I for one believe automation, and abstraction of the "how" from the "what", is critical to the future of security.  As system complexity grows, environments organically grow into hybrid implementation of on-premise plus cloud services and technologies continue to be stuck together through acquisition and implementation - the only way to make sane policy-based technology changes is at the abstract level.  Saying something like "every (virtual or physical) machine must have access into it limited to only ports from required, trusted sources.  Whether you're implementing VMWare, or OpenStack the "how" of this policy isn't something a rare security resource should concern themselves with, rather, they should be concerned with the "what" meaning that policy statement.

 

Cloud is like this too.  When we make the decision to 'segment' high-criticality systems from the rest of our virtual infrastructure we don't really care what the means of doing this is ...only that it gets done, right?  Wait ... or do we?  Does one way of limiting access on a Linux system differ from another way on a Windows machine?  The answer is obviously yes, but the real question is - does the analyst need to care?

 

It's an interesting question ...and as we abstract more and more with system complexity going through the roof, these are important questions to think about.  Ultimately I think the answer to whether abstraction helps or hurts security is, as you would expect, "it depends".

 

If you want to do security at scale for the modern enterprise, you'll need automation and by extension abstraction.  This 'must have' of course doesn't mean that you can ignore the technical implementation details and consider it someone else's problem... or well, you can, but understand that this will eventually train wreck, badly.

 

While abstraction seems to be the natural evolution in our ever increasingly complex world, we need to be mindful that we don't let ourselves forget how the gears of the back-end work... lest things break and we not know how to repair them by hand.

Comments
Ricky Cielma(anon) | ‎11-14-2012 06:38 PM

I think you're right - "It Depends".  Automation is great, but it does relax the mind.  Something or someone is doing something for you.  Therefore, it takes the human element out of the equation - that's great in some cases; especially in operations.   When it comes to security don't you want both the automated process and the human involved?  More automation makes it easier to grow without adding personell overhead, but it leaves gaps in your security processes...maybe.

 

At what point does abstraction become a systemic problem?  

Sergio Pozo(anon) | ‎11-15-2012 04:21 AM

I also think that it depends. Ricky raised the point here: in organisations where operational costs are high, provably security problems are also important and a high abstraction makes sense. So, for every day rutinary tasks, an automation tool is OK. However, for small changes or non rutinary ones, you may want to touch the CLI (what the hell! a CLI in 2012? ;) ) In addition, the training of the person using the automation tool is usually not tiered to a particular vendor or technology, and he or she is never going to touch the CLI at all. So, the problem here is that people is changing as a consequence of tool usage. This has also happened to other systems (think about how Windows has popularized the use of personal computers in contrast to the early MSDOS, or about programming in assembler Vs Java). At the end of the day, there are cost and quality reasons. And no human beats an automation tool in these two non functional requirements ;)

 

For me, the point is to give the user (system administrator, operator, analyst...) the freedom to select the abstraction level he or she wants to work with. And that's what we do in Intelliment Security.

 

Really good discussion :D

 

Cheers

Sergio Pozo, Intelliment Security CEO

http://www.intellimentsec.com

secolive(anon) | ‎11-15-2012 04:46 AM

I've come to the conclusion that abstractions are powerful and actually the only way to understand complex systems (and hence design them properly). However, not understanding the details of those abstractions is a major source of security issues.

 

For instance, take SSL: it's a very nice way to get an abstraction of a secure communication channel between two parties - a tunnel, you push something in, and it gets out the other end securely. And here, "securely" almost means the naive "perfect security". Practically, you can safely abstract SSL as "perfect communication security". Very powerful abstraction, don't you think?

 

But wait, what about verifying certificates (including hostname, validity dates, chain), hardening your trust store by removing unneeded CAs (cf Diginotar), checking the CRLs, limiting the algorithms in use (MD5 anyone?), etc...  Don't understand how SSL works and its limitations, and you end up with perfectly insecure communication, as demonstrated by numerous applications which do not bother checking certificates.

 

Use abstractions in order to comprehend more complex systems, but make sure you understand them very well. The devil is in the details, and it is 200% true for computer security.

Screamingbyte(anon) | ‎11-17-2012 11:50 AM

Very interesting that you mentioned that you haven't done ACLs in a long time.  Isn't that something a beginner in infosec would handle?  My point is, that it seems that there are two different levels here.  We assume that those in a higher (macro) position don't care about how it gets done, as long as it does get done.

But these are also the people who have been there, done that.  We've already discussed the problem over and over that programmers can not always be counted on to adhere to best practice, etc...  So, how do we know, for a fact, that the underlying tool is actually configuring correctly?  Well, auditing, of course.  But doesn't that begin to negate the very benefit in the first place?  If I have to understand how an ACL will limit traffic to a one-way trust, and then I have to test it to make sure the implementation is effective, then how is the tool really helping ME as the grunt who has to do it?  Sure, some ACLs can get very long and complex, but devil's advocate again, how can we be totally certain that the "tool" is doing it right?

I agree with you about abstraction, but at the same time, what about those who haven't "been there done that"?  We can pound security concepts into student's heads all day long, but will they remember the underlying concepts that are important to making those bigger decisions once they are seniors?  Can we trust someone to design policy who has never written a single ACL in their career and can't do anything without clicking an icon?  Should we trust them?  I guess "it depends", after all.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author


Follow Us
Community Announcements
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation