I’m going off the standard track for this post, as the whole session update thing on TechEd is a bit monotonous and besides, you can view the cool ones yourselves on Channel 9. What I want to do instead is share my thoughts on something that has been floating about in my head from all the sessions I’ve attended, namely ‘Security’.
One of my roles as a Solution Architect is to look at the Non-Functional Requirements of a particular system I’m designing. What’s a Non-Functional Requirement (NFR)? Well, it’s the bits of the system that don’t directly do something – as those would be Functional Requirements (for example, think of a login page or password reminder page as a piece of functionality that needs to be implemented).
A Non-Functional Requirement complements the Functional Requirement and basically applies boundaries to what the system should and what it shouldn’t do. NFR’s cover areas such as system availability, resiliency, performance, capacity, scalability, accessibility, for example.
I like to ask potential candidates which of these they think is most important to a system they’ve designed, or are going to design, as it helps me see if they have considered how a system will evolve or if it is robust enough to cope with user demands. Usually (but not always) Non-Functional Requirements are treated pretty much equal to each other. If the system isn’t available, the customer could lose money, and we could be in breach of SLA’s. If the system isn’t performing, the customer could lose money, the users would get angry and business could be lost if orders aren’t placed in time. If it doesn’t scale….you get the picture.
However, I don’t hold this ‘equality’ view anymore. I believe security is by far the most important Non-Functional Requirement a system can have. Why? Well, if an attacker can compromise your customers system, they have the means to disrupt daily work, anger users, delay orders, damage reputation etc as per any of the other NFR’s mentioned above, and this alone is bad enough. What’s worse though is that they also have the ability to steal the intellectual property that your customer has spent years and huge sums of money developing. This is much, much worse.
Plans, schematics, bids, quotes, source code, employee records, credit card information, medical information, voting records, tenders, contracts, customer databases, sales contacts, pharmaceutical formulas, criminal convictions – could all be gone in an instant. Once its out there, you’ve no chance of getting it back.
A single breach could effectively be a killing blow to the customer and your reputation as a service provider. The scary thing is that it’s getting easier to do; even scarier is that in some cases it’s state funded. Typically these attacks are focused at successful small to medium enterprises as well, as they haven’t the infrastructure or policies in place to implement proper security procedures and they are taking on a lot of new staff who aren’t yet familiar with how things should be done. Sound familiar?
I watched demo’s today whereby Lateral movement and Privilege escalation were demonstrated. What does this mean? Well, essentially it means using a low level account to move along a network from machine to machine and get access to another machine with the same account (Lateral Movement). You can then pull from memory any password hashes that are left by say, a recently logged in Domain Admin and using these, escalate your credentials (Privilege Escalation)
What’s a password hash? Well basically it’s a one-way transformation of your password into a token or series of characters. If you use the same password each time, you end up with exactly the same hash. It’s a one way transformation in that you can’t reverse the hash to get the password. If you change the password, even by one letter, you get a totally different hash.
Why use them? Well, a lot of operating systems use this approach for authentication rather than sending passwords about the network, as it’s very quick to hash the password and send that – which is sensible. However, it’s totally open to attack using tools such as Windows Credential Editor (WCE).
I watched today as the presenters demonstrated using WCE and USB infiltration devices like Rubber Ducky to compromise a system, simply by inserting it into a USB port. Within 3-7 seconds (slowed down for the demo), it had installed an number of back door passwords, executed a dump from memory (using WCE) of the hashed credentials on the machine and uploaded them to a website. Three to seven seconds.
The tools are becoming more advanced, and as systems become more complicated we have more surface areas to attack. The weakest area of all these attack vectors however these however is us. You and me.
You see, we are after all only human. So many sites, so many passwords. It’s easy to use the same one for all of them right? What about us as developers? You run Visual Studio as Administrator on your dev machine yeah? Turn off User Account Control? What about contractors? How much access do they have to your system? Can users install their own software? Bring in their own USB devices?
What can be done?
It’s an absolutely massive challenge that cover so many areas, but some key points are:
This is a really good article on the anatomy of an attack. Definitely worth a read.