Reorienting Towards Security Integration

Yesterday's post makes the case there are no security problems. 

I used to think we had security problems, and then we figured out how to integrate the security solution.

Actually, the security basics are long figured out, its the integration that's killing us. We don't have a security problem with integration requirements. We have an integration problem with security requirements.

The why is pretty easy to understand. 

1. Security is mainly an isolated department. Not really ops, not really arch and definitely not dev
2. Security is audit focused
3. Secuity is swimming in "products"

These problems are a direct result from how most security organizations and the industry as a whole functions. The combined effect leads to security's integration problem. 

Because information security is separate it does not get to collaborate in the key architecture, design, and deployment decisions in an effective way. At best, most groups function like a QA team that runs black box tests for vulns. Its an important activity, but if that is the apex then you are left Security as QA. A point in time activity.

Audit is of course a great example of an important but limited, point in time activity.Its not integrated along process, technology or organizational lines.

And so how does the security industry resolve its tactical role? With a panolpy of products, of course. Sure the security product markets has come a very long way over the last decade, but all the key questions with these tools are not so much on their efficacy, but rather on will they integrate to my process and my architecture? Sure static analysis can generate findings, but how do I parse through them? How do associate countermeasures? And by the way who does this?

Sure a WAF can catch some bugs, but will it work with my session manager? Sure the next great identity protocol can give me more fine grained access control, how do I get it work on iOS? And on it goes.

To resolve these issues, I would suggest we go back to the root of the problem and tackle them head on.

Security is mainly an isolated department. Not really ops, not really arch and definitely not dev

Security is audit focused

Audit will always have a role to play in security, there has to be an objective score card and someone who sets the hurdles. This function will remain, but it needs to be put in the right context to make it useful. The outputs of audit should over time lead to better design patterns that are based in a long term mindset for evolving the security architecture. Not auditor-driven fire drills - "ok quick, we gotta go deal with privileged accounts because even though we have had this problem for 20 years and so has everyone else, the auditor flagged it. Quick I need a seven figure budget authority - Aux Barricades!" 

Secuity is swimming in "products"

The audit focus leads directly to Infosec's product problem. The vendors are nothing if not observant. They know what's on the auditor's checklist this year. They will build products (or at least marketing materials) that will solve those problems or at least enough to get the auditor to cross off the check box.  Besides the obvious cost and resource problem here, there's a quality problem. Audit isn't architecture, its more a fashion show with problems du jour and acceptable modes of solution.

Again audit is not going away and neither are products. But just like audit, products need to be put in the proper context. That context is not what your audit checklist says, its your business process, your users, your customers, your threat model, and your system architecture. 

Reorienting means spending as much time on product selection and architecture on APIs, the integration points, the message flows. When I do Web services security design work, a pattern is almost always the security pipeline pattern. Why? its boring, its where the security enforcement happens. But that's why its important! Its where the security enforcement happens. Not the token or protocol patter, but is it a filter, a container, an agent, a standalone server. That's as critical as any other decision.

Why did Active Directory win? Sure they have smart programmers. So do IBM, so did Sun (Rest in Peace), so did lots of others. AD has connectivity and integration to users, to sessions, to servers and so on. Lots of people tried to get Kerberos to work. The differentiator wasn't Kerberos, Microsoft did the hard, crucial intgeration parts.

Security Token Services (STS) are a subtly powerful use case. Give me a Kerberos ticket, I give you a SAML token. Give me an Oauth token, I give you a SAML token. Support many different clients and keep the back end simple. Integration wins, not slamming pizza boxes in racks and telling scary threat stories.

POCs should never be isolated. They have to be run against as production-like system as possible. Every interface and API needs to be combed over to look for how exactly its integrating with your system. What system has session management? Where are the users logging on? Do they push or pull policies? What tokens are supported? Are agents required? The list of architecture questions is logn, but its path that must be walked. Security projects and security architectures succeed or fail not on the control or solution quality, but on how well the security system integrates with the system as a whole.

Part 3- Boring Is Good

Comments

[dunsany]

Hmm... I'd say a lot of ineffective security shops are swimming in products poorly integrated. We run pretty lean with a small number of "security specific" tools and frankly, get the most mileage out of the same tools that the IT folks use. That and plain old good decisions and risk education.

I'd also add: IT in general has an integration problem. Watching the Ops team flail around trying to get their SAN to work with their virutalization stack and their various enterprise apps is lesson enough that interoperable tech is a long way off.

[Andre Gironda]

Accountability in the lower input chains must be assured to make a higher value output chain. Process management (which barely exists in any IT environment I'm aware of) relates tasks-to-output. We can create higher-value outputs from lower-value inputs and we can secure them.

Do I have to say it? Security is about process, not products.

Love this thread, and have personally been obsessed with integration metrics since Visible OpsSec. Let's get to it!