SESSION 6Principles and Patterns of SecurityTheres no doubt about it, Ron Jacobs is a lively and interesting speaker. He kicked off with a quick plug for
ARCast which is a show on Channel9.msdn that looks at the latest architecture trends.
The focus of this session was firmly rooted in the way we (as developers) think about security. The speaker set the scene with a security related story about the American company TJ Maxx.
"But surely the company is called TK Maxx", I hear you say. I too thought that the speaker had wrongly combined the names TJ Hughes and TK Maxx into a non-existent company, but no, it seems that in the US it is TJ and in the UK it is TK. Anyway I digress.
Apparantly, hackers pulled up outside a store in Massachusetts and compromised an insecure Maxx network. The net result of Maxx failing to successfully encrypt their network was theft of 47.5 million customer credit card details. 6 people were later charged.
In the above scenario, the prime motivation for attack was obviously money ($1,000,000 was spent on merchandise and gift cards using some of the details). However, an asset does not have to be cash,. Other motivations may be:
- destroy customer confidence.
- Elicit personal customer details for identity crime.
- Hijack processor, storage, bandwith capabilities.
- Affect availability (e.g. DoS).
- Degrade performance.
So what are the entities within the whole attack scenario. Well i'm going to summarise:
- Assets are the things that the attacker wants to take from you.
- Threats are the ways in which the attacker will try to get the assets.
- Mitigation is the way(s) that you can block an attacker.
- Vulnrabilities are unmitigated threats.
The speaker then turned his attention to Threat Models which are assessments of the assets, threats, mitigations and vulnrabilities of a system you are building or have built. A useful exercise that Ron asked us to consider was to transpose the attack scenario onto a simple template which takes the format:
AS AN ATTACKER
I WANT TO ____________
SO THAT I CAN ____________
BY ____________
so an example may be:
"As an attacker, I want to obtain credentials so that I can plunder bank accounts by logging customers into a bogus website".
You get the idea.
Next, Ron turned our attention to security objectives or to put it another way, "what do we NOT want to happen!" well, we need to be real clear about our security objectives up front. It is no good to think of security as some kind of 'bolt-on' further down the development process.
The speaker outlined some basic security concepts:
Reduce you attack surface
Your attack surface is all the ways in which an attacker can get to you. It goes without saying that "the smaller the attack surface, the better" and the analogy he gave was that of a castle (not the doomed Microsoft project but a real live castle with turrets, drawbridge and things). When they used to build castles in medievel times, they would have minimal access (i.e. one door complete with drawbridge) and safeguards such as moats and those windows that you can only fit an arrow through. A key message here was "UNDERSTAND YOUR ATTACK SURFACE!" and take steps to reduce it for applications that you already have running in live. Document your attack surface and understand all entry points into your application.
Defence in DepthDon't just count on one line of defence for your entire system. What if the attacker penetrates that defence? We need to think about a multi-layerd approach and our next move to minimise damage once a layer has been broken.
Least PrivilegeAlthough least privilege can be seen as a
defence in depth measure it is best to give it the respect it deserves and treat as a seperate entity. It's as simple as this - CODE SHOULD ONLY RUN WITH THE PERMISSIONS IT REQUIRES (sorry for yelling). Attackers can only do what the code was already allowed to do. Ron offers some recommendations at this point: 1) use least privilege account 2) use code access security and 3) write applications that non-admins can use.
Fail to Secure ModeWhere possible, incorporate failsafe features into your application. DO NOT assume successful operation e.g. initialising all boolean flags to TRUE rather than false. Apparantly, some people do this in their code and wonder why hitting an exception (without a flag = FALSE statement in the CATCH block) causes the potentail attacker to proceed unchallanged.
Never connect to the database as SA. Why? because it violates the principle of least privilege and allows the attacker to elevate his permissions on the system.
Ron then stepped through some other nuggets of information which were pretty obvious things. Dont store passwords in unencrypted connection strings, use Windows security where possible, dont use easy passwords, use stored procedures instead of embedded SQL etc. etc.
In introducing his section on secure storage, Ron mentioned that almost every company on the Fortune 100 list have had security breaches due to insecure storage context. Data MUST be secured in all contexts, whether it be a laptop, a back-up, transmissions of the Internet or third party credentials (e.g. customers).
Never, ever attempt to write your own encryption algorithms in order to secure your data. There are brainy professors that have devoted hundreds and hundreds of years of combined research into this area. Use their work. You would'nt perform your own brain surgery now would you?
Remember... All input is
EVIL unless proved otherwise.
Excellent session.
Things have changed a lot since 1978. Over the years, the hardware has moved from the desktop model to client server to 3-tier to n-tierProcedural. Software on the other hand has moved prom procedural to OOP to SOA.
Legend:
Although there were so good tips in this session, it was of limited use for anyone who does already know the technology inside out. I left slightly disappointed.
We then moved onto the topic of Threat Trees which are graphical representations of security-relevant pre-conditions in the system. Basically, they are a refinement of the fault tree with the root node equalling the prime threat whilst the chid nodes equate to the questions that need to be asked. The leaf nodes are secondary threats that need to be evaluated.
