Security Architect

I'm on the hunt for my next project.  Okay, lets clarify that last statement, a project that pays!  One of the areas that I would like to focus on is that of Security Architecture.  Why?  Well maybe the rest of this blog will help with the explanation.

A couple of consulting gigs ago, I did a 2 year stint as a SA for a large retailer and I really enjoyed every moment there.  It satisfy my need to be introduced to new technologies on a fairly frequent basis. It was extremely satisfying to have personally involved transforming the company's business lines view of Security from persistent nay sayers to full fledge business enablers. It help drive my desire to develop ways in communicating security more in business terms.  For example, instead of Security Risk's Management, its Operational Risk. Threw out the formulas associated for explaining risk. And the colored tables that at the heart of it, a lay person didn't want to have to earn a PhD just to learn how to use it.  Instead, I described risk in terms of how security prevents whatever business solution from failure to deliver the goods and services to the client.  If you couldn't tell, I didn't actually throw the baby out with the bath water. Instead the experience taught me a valuable lesson. Security should be described in terms of saving money and if possible, make money.  And most importantly, getting to work along side some pretty intelligent and gifted people instead of just the machines!

Another area where my OCD helps out and one that I've been told I'm really good at is, process development.  Within this same company I had developed, documented and mapped out the intake procedures, project's documentation requirements, third-party risk management, escalation procedures, contractual review, risk assessment plan, independent assessor, and final deliverable(s).  I was even accepted to speak at a local security conference about what we had accomplished. 

If you are interested, here is the highlight of my presentation for implementing Security Architecture in a fast pace, bleeding edge company.

The TAO of SA

In my opinion, there are two different types of SA's, one who focuses on designing and implementing security services at an enterprise level, in line with service-oriented architecture (SOA) state of mind. Than there is the type I gravitate towards; as being someone who develops security requirements based on established security policies and standards, conduct analysis of the proposed design patterns, and conduct testing to ensure the security requirements have been met from the application to the infrastructure layer and everything in between.  
(And based on my recent interviews, a third version is on the rise, a software security architect.  As the name implies, defines the requirements and testing as the aforementioned SA is defined, but is more heavily centered on having a (professional) software development background)

Security Architecture Methodologies

To complicate matters, there are a few security architecture methodologies to choose from:

• SABSA - Sherwood Applied Business Security Architecture 
• OSA - Open Security Architecture
• ZACHMAN
• DOD Architecture Framework

Which one to use? In my opinion it needs to be a cultural fit, can be easily operationalized across multiple projects by one person and answers the basic needs of the company in determining the state of its security posture. Which I define as a company's resiliency to handle service disruption to the delivery of goods and/or services. I could be wrong, just going by what a couple of hundred security assessments across multiple business lines on what worked and what did not.

Goal of Security Architecture:

Security Architecture enables the business units and executive management to:

• Identify operation risks
• Validate appropriate controls are in place
• Meet privacy and data protection concerns from a reputational and regulatory compliance stand point

Each have their pros and cons, but they have a common purpose of providing a formal review process to ensure consistency and reputability for determining risk.  One of the most important component is threat modeling analysis (TMA) no matter what methodology your organization follows.

Threat Modeling Methodologies

At the heart of any SA assessments is Threat Modeling.  Here are but a few threat modeling methodologies to choose from:

• STRIDE - Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege
• DREAD - Damage, Reproducible, Exploitable, Affected Users, Discovery
• PASTA - Process for Attack Simulation and Threat Analysis
• Trike
• OWASP Application Threat Modeling 

Again, there are pros and cons, and is meant to provide some formality and uniformity in identifying risk to whatever you are trying to measure.

Goal of Threat Modeling:

The goal of threat modeling should be to:

• Identify what, where, when, who and how informational assets will be utilized
• Identify where the riskiest points exists
• Determine where the appropriate controls should exist at the application and supporting infrastructure layers

Summary

As far as methodologies, I'm partial to OSA.  This to me provides the quickest and most logical approach.  Besides understanding the business requirements, this methodology works best at translating what the informational assets touches, handles, transmits, stores, processes, and transforms to which security patterns will offer the best means to thwart what is currently available to detect and prevent most threats known today.

Regarding threat modeling, for software/application based assessment, I think that OWASP Application Threat Modeling  approach makes the most sense. This model utilizes data flow analysis which is complements OSA.  Including a library of threats that could have an adverse affect each touch point (i.e., touches, handles, transmits, stores, processes, and transforms) could be susceptible to.