1 Raindrop

Assume a Secure Endpoint

 

This is a snippet from my Cloud Identity Summit talk, there is an old physics saying- assume a spherical cow of uniform density. Thanks to Marcus Ranum we now have the infosec equivalent -  

"the endpoints we have so far never made any successful effort to secure, which we will assume forthwith to be secure.” 

 

Tao of the Software Architect

I have long been a fan of Philippe Kruchten's work 4+1 showed a new way to look at software architecture and I still consider it the defining work in the profession due to its simplicity and clarity.Philippe's Tao of the Software Architect is a little known gem, one of my favorite parts:

When the process is lost, there is good practice.
When good practice is lost, there are rules.
When rules are lost, there is ritual.
Ritual is the beginning of chaos.

You can see this play out in infosec over and over again. 

We try for Security in SDLC

When that fails, we try for better coding, deployment practices, checklists and tooling

When that fails we update policies

When that fails - chaos.

Of course, it does not always fail, and I think turning this list on its head and working from the bottom up is the way to go for most companies. So many companies start with "we need a Secure SDLC!" No question about it, you definitely do buddy; but first you need to have policies, tooling, coding practices, training, and checklists all in place before that can happen. If you try to go straight for the Secure SDLC you will likely cascade to fail.

There is a lot of ritualistic behavior in infosec - determining priorites based on an auditor spreadsheet or what you did last year, but rituals are not substitute for thinking and pragmatic actions. I recommend that you eschew top down. Good SDLCs are built from the bottom up - with training,supported by tools, and simple to follow checklists and guidelines that make doing the right thing easier.

Software Security - Putting Hippies and Nerds to Work in the Right Places

Many years ago Robert X Cringely sagely observed that there are only two types of programmers: hippie programmers and nerd programmers. The Hippie programmers do the right thing, the wrong way. The ner programmers do the wrong thing, the right way. I will pause a moment here for you to mentally categorize the programmers you have worked with.

There's lots of examples of these personality types in software security, introducing nonces to deal with CSRF is a nerd programming idea, it attacks the CSRF problem, but it does it the wrong way (introducing state in the middle tier). As for Hippie programming examples, doing the right thing the wrong way, how much time do you have? The entire Internet was built this way.

In security, we're often faced with the choice of doing the right thing or doing things right. This comes up over and over, and a recent post by Sejal Kamani on Fortify's blog discussing SAP/ABAP security shows why

What is immediately evident is that even today most of the time and money spent in securing SAP systems revolves around authorization checks, single sign-on, SSL, segregation of duties and other security features. As important as these components are, it only tells half the story. Very little is being said and done about securing these systems at the application level.

Initially, this was not as big a concern, as most of the SAP systems were internal to the enterprise. But with other software systems, as they established an online presence, ABAP applications were found to be vulnerable to the same attacks that have plagued Java and other web applications for years.

The post goes on to list common web vulnerabilities like XSS, Command Injection and Path Manipulation where SAP has vulnerabilities. There are some reasons for this such as the good ol' we're inside the firewall assumption which was valid until it wasn't.

Sejal concludes that "And as SAP systems hosting business critical applications move online, SAP applications should be held to the same software security reviews and standards as other web applications." I would go further and say that because of what SAP systems represent - your business supply and transaction chain - they should be held to a higher standard. Assinging security review priority based on downside risk is an oft-missed distinction in our threat obsessed industry. But that is not the point of this post, the SAP example illustrates that what's necessary to deal with malice is not the same as access control. 

Infosec teams need to define distinct roles in the chain of responsibility for Access Control and Defensive services. 

Access Control services deal with Identity and Access Management, and perform authentication, authorization, attribution, provisioning and other services. These are crucial enterprise security services, but they mainly relate to getting people who work for and do business with you the proper credentials, policies and tokens to do so. They do little defend against malice, for that we need...

Defensive Services are services that deliver a Margin of Safety to the enterprise through attack surface reduction, monitoring, encryption and other methods.

The distinction between Identity and Access Management and Defensive services are that the former can be found in functional flows and use cases, the latter are conservative architectural elements and processes for that which is outside the spec.

They are both critical to security architecture, they are both mainly sourced out of the information security team, but other than that they have very little in common with each other. In fact the staffing models, tools, skill sets required and where and how to participate in the SDLC to deliver these two Security service types could not be much different.

The foundation of the Security Triangle shows the differing mindsets at work. Identity and Access Services are about doing the right things -authenticating and athorizing your employees, customers and partners. Have Hippie programmers build these. Defensive services are about dealing with malice - defensive coding, input validation, output encoding - have Nerd programmers build these.