1 Raindrop

DMZ and Headless Chickens

I know a few folks who are into this little microtrend of having chickens and chicken coops. They all have a similar story. Things were going fine, then one day a fox/weasel/raccoon found its way through the coop protection and they woke up to a coop full of headless chickens.

John Lambert says " Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win."  I am a big fan of checklists as a way to avoid mistakes, but they do not have a role in design or telling you what to do. That's a very important nuance for defensive architects to grasp.

Symbols are very important in how we process things. The classic DMZ design shows a layer of protection between the big, bad Internet and the soft chewy enterprise center.  One problem with list thinking is that it can lull you into a false sense of security. Like Brian Snow says the worst thing is not being insecure, its assuming you are secure, acting accordingly when in fact you are not secure. 

The DMZ concept by itself is not the problem. However there are knock on effects of the mindset that we must guard against as security architects. The DMZ conjures up an image of highly trained, highly capable people and technology rigorously scrutinizing inbound and outbound flows. Keeping the inner sanctums safe. Reality has diverged from this. 

The other problem is that while the DMZ is an important layer, it neglects to address one the most fundamental questions in all of engineering - failure modes. What happens if some malicious code gets back to the back end? What happens if the attacker can move laterally? You get headless chickens. 

The industry today is geared toward making a safer chicken coop, strengthening the controls and DMZ structure is where 99% of security dollars and attention go to. Auditors then come along and ask if you have 17 controls on the coop, why not 18, why not 24? No doubt this is all important and hardening matters a great deal. 

But today you have to assume that lengthening the list of controls on the DMZ won't stop the determined opponent. So the next question to ask is, assuming the attacker's graph gets them by the coop walls, what next? 

In other words, assuming a chewy center how to avoid a coop full of headless chickens? That question leads you to a number of deeply suboptimal tradeoffs and unappetizing choices. 

My take is that we have pushed the DMZ concept very far over a long period of time, and just like that third cup of coffee does not have the same effect as the first two, we need to look to some new areas to improve.

Those directions of change need to come without and within the coop walls. Some of it is better recognition of malice, some of it is better response. Many companies are embarking on unflattening (unchewifying) the centers. This could be through stronger (in many cases any) authentication, fine grained authorization, segmenting networks, using gateways to reduce attack surface, tokenization, limit options for lateral movement, integrating monitoring and access control with risk based access control and finally taking a hard run automating key management. If the "lose less" design cannot save all the chickens perhaps it can save the flock as a whole.  

These are long tail projects that reshape the security architecture, yet they also require process changes. Process change is far harder than technical change, and its effect on project deployments is almost always underestimated. One of the reason the DMZ continues to receive investment is that its already assumed the normal rules do not apply there, so adding an 18th control is not a problem. However, once security architects seek to change Inside systems, totally different rules of engagement apply. It pays to be conservative in the short run as to what you can achieve in terms of process changes. 

The nature of security capabilities is different here as well. The key to unlock this is threat modeling. Threat modeling is usually done with how hard is it to bypass the DMZ. Some part of threat modeling should start with the assumption, "now that the attacker is on step 2 and inside the system" what happens? This second question is not often asked. Hardening is the de facto standard in the DMZ and it should be. Inside the system segmentation or tokenization may matter more. One chicken is lost but the flock makes it. Stronger authentication to limit lateral movement, so one system has an issue but not 2,000 internal apps and database. User activity monitoring to watch the inflows and outflows and detect/respond when there is an issue. 

The famous crunchy shell and soft, chewy center does not work so well with a determined, graph executing opponent. Its worth asking if the next $100 you spend on security capabilities should be used to further harder the crunchy shell or should it be used to make the center less chewy and more resilient? Or perhaps we should change the nature of the game itself with something like tokenization or risk based access control.

Basically, this is an effort to get to graceful failure modes in security. Unfortunately, we currently have a system today where everything works or its all chickens dead, game over. There are more directions that this can go, but changing that one assumption and making sure you design for failure of the core security capability itself is a key to long run system survivability.

Decision tree for calculating breach cost

Professor Sanjay Bakshi published the below list in response to the Maggi issue that Nestle is dealing with in India:

We can use the same decision tree to figure out impact from breaches or other security events:

1. Will the size of the addressable market be larger or smaller than it size just before the breach?

2. Will the company’s market share be larger or smaller than her market share before she landed in a jam?

3. Would  the company need to spend more money on fixed assets and working capital to defend its market share?

4. Would the company have to spend more on Advertising to gain back its reputation? Would it be appropriate for value investors to treat ad spend as an investment instead of expense?

5. Would owner earnings generated from each product/service be higher or lower than before?

6. Would  the company have to raise prices to compensate for better quality?

7. If yes,then would that result in shrinkage of market size and its market share?

8. Would the company have to pay significant penalties and fines to get out of this mess?

9. If the company is guilty, would  customer forgive her?

10  Is this a strong signal to companies that,in this age of instant information dissemination, they can no longer have have different quality standards for their products sold online versus offline?

11. Are there other cockroaches in the kitchen?

This a very good start at the important questions to ask and substantially more detailed than cost per record or how much it costs to pay for credit monitoring. I mentioned in my previous breach impact analyses that the places to look include revenue, margins, cash flow, debt and customer retention, those metrics and others are a good way to measure the impact (if any) to the above questions

Water in the Fuel Battling OWASPs' Nest

Belgium has contributed a lot to the infosec world, for example Rijndael and a great conference- SecAppDev. Plus Hercule Poirot.

Its commonplace now for people to say they want to "build security in", but its worth noting that saying build security in is a lot easier than actually doing it. All sorts of questions come into it, what kind of security capabilities do you want to build? Where? What about legacy migration? What quality of protection to shoot for? Should we strengthen the weakest link or build stronger centers?

Oh, and once I have a design logic that incorporates the above - how do I make it as easy as possible for developers and admins to integrate these security services cohesively? This last part is the trickiest of all and it gets the least attention.

However, it did not escape the studious gaze of the famous Belgian detective. Hercule Poirot said the Wasps' Nest was the most challenging case of his career. What makes this case so challenging is that Poirot is investigating and ideally solving a murder that has not happened yet.

This is precisely the challenge we face in security design, getting the point across to developers that we need to build more secure code, yet at the same time security architects have to point to attacks that have not happened yet that leverage vulnerabilities that (often) have not been created yet (because the code is still under development). No wonder that securityspeak often sounds so convoluted. Mitigating theoretical vulnerabilities against theoretical attacks, may as well be speaking Mandarin.

So how to combat these two issues? Make things as concrete as possible. I see three main areas: one ensure there is clear guidance on what the defenses should look like. Two, each of these security capabilities should be backed by a battery of test cases. The test cases should show both that things are working as expected and that known downsides are avoided. Gauntlt is a good example, if you are an agile shop. There is a lot more that can be done. For example that authorization is working at the right level of granularity, that TOCTOU and concurrency, CSRF and other attacks are mitigated.

Three, a clear signal to developers and admins that shows things are installed and configured properly. As an engineering philosopher observed - "There's a light in diesel trucks that says 'Water in the Fuel', well when that light comes on, well, that means you've got water in the fuel. leave that light on too long and your truck just dies." Despite the billions spent on infosec, we provide no such clear signal or guidance to developers and ops folks that could tell them whether their efforts are on the mark or not.

How to interview prospective employers

These days, security people have a lot of opportunity. Between a recovering economy, ongoing high profile security issues, budgets and executive attention - more than ever before security people have options. You spend a lot of time at work, more than almost anything else, so it pays to be choosy on how you spend your time. Here some thoughts on how to identify where and how you may be challenged and rewarded.

First off, do not just look at the company name or the job title. Those have little to do with job satisfaction. I know people at big name tech firms and game companies that would seem glamorous, and they strongly dislike their jobs. I have seen people in humdrum industries that have long running, enjoyable careers. The label on the company and title are not in the top 10 things to consider.

Sure, you need to care about things like compensation, benefits, and bla bla. But in the long run I think its simply about this - can your infosec work make a difference?

The people i see that stick with the companies and enjoy their work all have one thing in common, security is valued.

So the analysis to do for prospective employers is really around - can your infosec work make a difference to the company, to its users, to its long term competitive advantage? How is security viewed in the context of the overall enterprise, customer relationships and ongoing mission?

Too often, infosec ends up being compliance drive or checkbox Olympics or department of No (that eventually gets the run around). These people get burned out quickly.

This is not to say you will be in a position where you win all battles. Security is like baseball if you get a hit 3 out of 10 times you are in the Hall of Fame. But there is a big difference between hitting 3 of 10 and not even being allowed to swing the bat, not getting invited to key meetings, your input not valued, or maybe worst of all viewed strictly as a compliance, CYA activity.

Here are some things I would try to suss out in interviewing a prospective employer.

* Where does the CSO report?
By itself does not tell you much, but can indicate how security is viewed. If the CSO reports to the CFO versus CIO this could alter what the expected outcomes are.

* What is the typical daily/weekly/monthly decision set for your role?
If its just running scans and posting stats, you may be farting in a hurricane. Its important to know not just what you design/build/test, but where and how those are used. Who are the consumers of security services and how widely are they distributed? Security is filled with subjective 60/40 decisions, which ones is your role responsible for and in what capacity - end decision maker, implementer, advisor?

* What are the hurdles towards security improvement?
If its “well avoid this team” or some such, that should set off alarm bells. If you feel like infosec is a treated as something only to be gamed that should as well. A long time ago I was in a company where security was a game, but I asked some harder, and I thought important, questions. I tried to be mild mannered, not jerky, but this simply “wasn’t done” and resulted in a director throwing a pencil at me. Also: if someone throws a pencil at you for asking basic questions I would say - avoid.

* Is security centralized or decentralized? What teams does security partner with and how?
This is a huge factor. Security cannot practically be delivered in a centralized team any more. Partnerships are absolutely huge. Do you have exec air cover? What is the mandate for working with developers, ops, and “the business.” What is the cadence and nature of engagement with other teams? Are they, heaven forbid, actively seeking out security team for guidance on architecture, design and development issues? Where its a proactive pull not only a security push?

* Speaking of “the business” - what do “they” see as primary security goals
Is it brand reputation? Operational impact? Customer retention? IP Protection? Throughput? This will tell you a lot about how empowered security is likely to be to facilitate change

* What does “good” security look like?
Steve Markel, who runs an eponymous insurance company, winces every time his office phone rings. Why? As he says - there is no such things a good incoming call in the insurance business. Security is similar, it tends to be a capability where you work your butt off and if you succeed you get a C and if you fail you get an F. Usually, these are types of situations to avoid, but alas that’s the business we’ve chosen in infosec. Does your propsective employer recognize this and how do they deal with it?

These are just some questions to get started, please add any other ideas in the comments

Security, Fast and Slow

A couple of observations to open up “We systems people regarded the users, and any code they wrote, as the mortal enemies of us and of each other. We were like the police force in a violent slum.” That's from Roger Needham, talking about the early days of infosec. So if you think about it, not that much has changed. 

That in itself is a problem. According John Foster Dulles - “The measure of success is not whether you have a tough problem to deal with, but whether it is the same problem you had last year”

Infosec has many problems, its a complex business, but perhaps the biggest problem is that not much has changed in the last few decades

Let's consider the OWASP Top Ten. Chris Hoff asks "why doesn't the OWASP Top Ten ever change?" Its true that the OWASP Top Ten is largely the same as it was in its inception over a decade ago. However, that's not due to laziness on the OWASP team's part. Quite the opposite, in fact, you'd be hard pressed to find a more dedicated, hard working bunch than the core OWASP folks. 

The reason the OWASP Top Ten remains static is that we flat out have not made much progress in the past decade. Every year, there is a big OWASP AppSec conference, the organizers try to figure out - should it be in NYC or West coast? What about Austin, that's a cool city? My vote is always for holding it in Punxsutawney, PA, security is Groundhog day. Same issues, different year.

If you really boil it down, what we are trying to accomplish in security is to act as a barrier between devs, Business folks, ops and others and keep them from doing something stupid.

and you might say, well yeah but we are doing this or that with Cloud and Mobile. And my response to that is - yes, same thing - we are the barrier between devs/business/ops and doing something stupid with mobile.

 So then the question is - how can we serve our companies as the most effective stupid barrier that we can possibly be? I found the answer to that, as well as an explanation to why the infosec industry has underperformed for so long, in a book by Nobel prize winner Daniel Kahneman called "Thinking, Fast and Slow."

The book explores the brain's two different operating modes. Which Kahneman named System 1 and System 2. 

• System 1: Fast, intuitive, frequent, emotional, subconscious 2 + 2 = ?
• System 2: Slow, effortful, infrequent, logical, calculating, conscious 18 x 23 = ?

Once you notice these two modes, you can feel your brain operating in one mode or the other. If you look at this picture:

Many dozens of things come to mind. Travel, culture, a baguette, the movie Ratatouille, and plenty more. You do not even have to think about it, it just happens.

Then there is System 2, best characterized today, April 15, as slogging through your taxes

 

System 1 excels at answering questions like - What’s the capital of France? System 1 is

• Associative memory, you do not have to decide, it just happens. Like seeing that someone’s hair is dark
• You are conscious of the results and your impressions, not how it happens

Contrast that to System 2 

• Laborious, effortful. Compute things – what is 24 x 17?
• Supervisor function. Can trigger System 2 processes. Best case – it should be the error correction function, recognizing when you are prone to error

Here is one big reason why you should care about this distinction. In a  nutshell- System 1 usually wins!

 When people are offered life insurance in two forms:

1.Life insurance that pays your heirs if you die in any event, or..

2.Life insurance that pays your heirs in the event you die in an act of terrorism

 

People are more likely to choose the second plan.

Takeaway - Simply making rational arguments isn’t good enough to influence better decisions

 Now if we take those two systems, System 1 and System 2, and look at how they play out in a security design discussion. Here is what we get:

The work that comes out of Dev (System 1) ends up being pretty informal and Agile. It gets sent over to Infosec (System 2) which in logical fashion looks at the downsides and inevitably rejects some portion of or all of the plan. Now the important question here is - is that an effective stupid barrier? Is simply telling developers that this is too risky effective? By itself I would say no, not sufficient.

 Because the System 1 system probably still goes live, and if you peel it back, you can look at the whole Dev-Infosec interaction through the System 1-System 2 lens with the developers making requests in System 1and the infosec team responding in System 2:

And part of the issue here is that security solutions are almost always creatures of System 2

These are all good ideas on some level, but none of them are simple and fast. And simply slamming these System 2 ideas to a System 1 consumer is a recipe for failure.

When you say "I wish the devs did data classification or threat models", what you are really saying is- "I wish software was written with System 2." Whether it should be or shouldn't be is an irrelevant question, its not written in System 2, its written in System 1. Your security plan has to factor this in otherwise you are causing confusion and delay.

Fixes must be addressed in a systematic manner too. You can't slam a playbook of System 2 ideas and expect it all to work in a big bang. Aim for a balance

The reality is that System 2 infosec has to create System 1 interfaces and activities to drive value.

The work then is not just to identify security logic in System 2, that is step one. The work then becomes making System 2 ideas drop dead, drag and drop simple to consume in the System 1 world in which the vast majority of the enterprise exists in. Find the linkages and integration points.

A comment by David Shaw says it well:

"It certainly helps to focus thinking about the payback (or lack thereof) we see in projects like some GRC 'automation' implementations (System 2 response paying lip service to System 1 interactions).

I also wonder whether a marker for robust, maturing infosec posture is that any measure introduced that delivers a System 1 outcome should have a System 2 corresponding capability performing analysis on effectiveness, efficiency, relevance."

And so the role of infosec is not to live in a System 2 ivory tower. Yes the security logic must make sense. But to be effective in practice, the security logic must be translated into something - process, tools, automation - that makes simple to consume for devs and others in System 1.

Based on observations over the years, it feels like there is a Constitutional law that says you must include a Sun Tzu quote in any infosec work. Now I am not going to revisit the ones you have heard before many times, instead here is one that I think is just as relevant as know your enemy. This quote from Sun Tzu encapsulates our grand challenge in infosec as it relates to improving and normalizing System 1 and System 2 relations:

 

Applying that then to our infosec world means that we must only deliver System 2 requirements that are back by readily consumable System 1 capabilities:

So for some rules of engagement here:

• Have a balanced approach - both systems matter
• You must always plan for System 1
• Challenges
• How to get System 2 concept to System 1 “no thought required”
• How to integrate
• How to automate
• No more than a few System 2s at a  time
• Ownership
• Let other departments own System 1
• Never dump System 2 on someone else

 You can define hardening profiles and scan for vulnerabilities all day long in System 2, but it won't matter as much as embedding those scans a la gauntlt into an Agile process because that's where developers and code live. Let's take another concrete example, which I call Alice in Maliceland.

 

First we have Access.

 

Now the normal way that infosec seeks to mediate communications between Alice and Bob is access control - authentication and authorization. However, this leaves aside the issue of Malice.

 

So access control by itself, while necessary, won't cut it here. One reason is the System's security architecture itself.

 

All the way back in 2004, Rich Mogull highlighted the chewy center of network security. John Foster Dulles would be disheartened to know that this is still a problem today. 

 

Back to our System 1 and System 2, think about that compared to the DMZ architecture. What is the DMZ, but a teeny, tiny island outpost of System 2 with its own special rules, meanwhile System 1 reigns supreme absolutely everywhere else. 

 

Beyond the enterprise, that design has real consequences for users:

So what is a better and more effective approach that we can take in the real world? Its up to infosec and security architects to navigate the balance between Designing for Access and Designing for Malice:

 

Defining authentication and authorization services help to determine who has access to what. It does little to deal with active malice. The access control model is the starting point for malicious users, not the end game. Dealing with malice on some level assumes you will not win every battle, that's a healthy outlook for defenders. Tokenization is one of the major improvements in recent years. What is tokenization other than saying, yes we will lose some data/transactions, but we will limit what we lose? This is a fundamentally different approach to security rather than the classic access control which seeks to contain everything in a policy of allowable/non-allowable.

 

Where access control is concerned with Alice and Bob, designing for malice focuses on threats from Eve and Mallory:

Now this level of reconciliation cannot be pushed down to developers, it needs to be thought through by security architects, but there is a final level of simplicity required to integrate this smoothly. One example, is using fine grained authorization to manage your attack surface.

 

Here is a classic access control scheme, user asking intelligent guard for a resource:

In the case above, the guard is intelligent and deft enough to fend off the wily requester. Unfortunately, not all guards are this intelligent and determined attacker could find a better place/guard to attack

 

A determined opponent will use brute force, target selection, fuzzing, different combinations and permutations to bypass the guard.

 

The net result here is that we need security architecture that finds the balance between access and malice,  guards that offer more intelligence in protecting resources, can recognize brute force and more clever attacks, have a way to discern friend from foe, and monitor the system. Finding that balance is very much a System 2 job for Infosec, however to create value for our enterprises, we need to always ensure that there are targeted System 1 outputs that can be readily integrated into real world systems.

 

The mantra for getting from System 2 to System 1 is best expressed by Antoine de Saint-Exupery: "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." A security architect knows she has achieved perfection not when there is no System 2 capability left to add, but when there is nothing left to take away from System 2 and embed within System 1.

 

 

Reverse Engineering Incentives

  

"Never, ever, think about something else when you should be thinking about the power of incentives" - Charlie Munger

In 1980, Wal-Mart implemented a shrink incentive program. If the store holds shrinkage (theft) below a certain level the difference in the amount is reflected in the associates' pay. They reported that their shrinkage level after implementing the program was half their competitors'. Sam Walton also mentioned the associates felt better about each other because no one enjoys stealing even those who would do it given a chance. 

I've often said that no one wants to write insecure code, and I wonder if something similar would work in infosec. Could a company put a fixed number each year towards an "average" breach cost and then if one does not occur, credit it back in a bonus to the tech staff, developers and sys admins?

Think - digital version of days since last workplace injury. My guess is that incentives along those lines would very probably work way better than the majority of products on RSA trade show floor, and at a fraction of the cost.

I think the single biggest change is soft. Its very hard to do as a security vet, but close your eyes and imagine the feeling of a walking up to a group of developers or sys admins, and having them glad to see you. That is night and day from most places today. I think security people would enjoy the feeling of being welcomed for their skills instead of shunned and avoided. To put it bluntly, as someone who helps people get their bonuses rather than ensures they don't get it.

There are some practical issues to getting this incentive realignment to work. Like - how do measure what good is in security?

To really try and do this at scale in an organization and to do with with real money and bonuses on the line, I would go with what  Ken Thompson says, "when in doubt, use brute force" Simple is usually better, so rather than going into the weeds on figuring out each incident, or each bug and assign individual responsibility - the measure could be something like "headline risk"

Yesterday was the 26th anniversary of Exxon Valdez oil spill. In infosec we have plenty of recent examples in Target, HD, Sony et al. of company changing events. So the incentive could be based on some kind of measure that says "we do not end up on the front page of the newspaper in a breach story" means everyone gets a bonus payout roughly equal to what we would pay in response cost on a rolling two years basis. This should tend to focus the mind and inspire people. Fired up? Ready to go? Now let's go install some patches!

Of course, the headline risk could be seen as too blunt an instrument and you may suffer for other's performance, but security is a collective responsibility. If you wanted to divvy it up into pay for bugs found, then there is a perverse incentive issue. Creating the supply, also know an as the Texas rattlesnake problem

" So, to demonstrate the perverse economic incentives underpinning American health care, [Munger] recalled a story about rattlesnakes.

In a small Texas town, the local government had an idea to combat the growing snake problem. They offered a bounty for every dead rattler brought into city hall. The next thing they knew, everyone in the town was raising rattlesnakes.

This well-intentioned incentive didn’t solve the rattlesnake problem, but it does well to demonstrate the perverse consequences created by health care’s fee-for-service model.

As an example, Munger talked about one surgeon who was known for removing normal gallbladders. Having been caught doing what most surgeons would describe as inappropriate surgery, what was his response?

The doctor said taking out a normal gallbladder was a reasonable way to “prevent disease.” He said he was helping his patients avoid the dangers of a possible rupture. However, this almost never happens in people with normal gallbladders.

Of course, this isn’t the only instance of a doctor abusing the system. In cities like Miami with a surplus of doctors and facilities, we see twice the number of tests, procedures and hospitalizations than in other communities. Whenever a group is paid to do more, not better, the outcome isn’t hard to predict."

That could is an issue for sure for any pay for bugs type of scheme (Chris Walsh calls this the minivan problem). So then defaulting back to big ticket events and headline risk makes sense.

Its not perfect of course, but has the advantage of focusing attention onto the issues of strategic impact and puts security people, developers, sys admins and other on the same side of the table. To me, this is long overdue and a powerful organizational tool. Its never a process or tech problem, its always a people problem. 

There is a temptation to say this is not fair, you could be penalized by someone else's mistakes. But bonuses are often based in large part on large events and outcomes where a lot of it is out of control for any one individual. However they still work. People are rewarded in large ways based on how well the company stock does. This has proved a very powerful motivator, and yet its not in hands of any one individual to create the outcome with the stock price. Still it works to focus attention and organize efforts.

Some might argue that incentives are silly, these are professional developers. What we need is regulation. We have used regulations, for example PCI or Company security policies, for a long time in infosec, they are not worthless, but they are not optimal either. At the very least they are only one tool in the toolbox and we should look at others.

Security people's main role is to be a barrier between an organization and stupid. So the real question is - what kind of barrier is the most effective? Regulations create the hostile, tactical and divided environments in which security people operate today. Bonuses have a way of getting people's attention I have noticed and they have a way of getting people to work together.

Ross Anderson was the first to point out the role of incentives in infosec, making them at least as important as security policies, mechanisms, and assurance.

Its not like we have not tried regulations, would it not be worth trying incentives too?

What I think the outcome here would look like is to simplify the coordination between the security team and dev/ops teams. On any engagement I easily spend 30-50% of my time on James Baker-style shuttle diplomacy trying to convince devs and ops folks that security is not deliberately setting out to destroy their timeline, bonus and career. If you just took that portion out of it, that means that any security time and dollars that get spent are spent on trying to solve actual security problems not Security/Dev/Ops Glasnost. 

One measure of success I use in AppSec is to identify the point at which the number and severity of security bugs reported by the Dev team exceeds those reported by the Security team. When you hit that point, and few have, that is about as good as it gets in terms of teams collaborating effectively. So anything that can happen on an incentive basis that quickly moves your organization toward that without introducing perverse incentives (minvans and rattlesnakes) seems like a major improvement.

Sunday in the Park with George the Auditor

Have a look at this painting by George Seurat. Its a beautiful scene, no?

While the paining looks like an organic whole, its actually a great example of pointillism -a "technique relies on the ability of the eye and mind of the viewer to blend the color spots into a fuller range of tones."

if you zoom in on a pointillist painting, you can identify how the contrast delivers a synthesis in the painting.

At this point, you might ask - fine, but what does this have to do with security architecture?

In a perfect world, its preferable to define a design for security services, and as projects go production then to have security architecture emerge, fully formed, to deliver capabilities based on business and technical requirements.

In the world we live in, many of the high priority issues are driven not as much by technology, threats, or even business requirements. Instead a lot of the Information Security team's agenda is driven by Audit. This is often used as an excuse for not delivering on this or that security service, but Audit shouldn't be viewed as a burden, indeed it can be viewed as an opportunity for improvement. For one thing, Audit elevates you to a fundamentally different discussion level. Audit has a strategic gravitas that most infosec tactical operations lack.  The challenge then becomes - how to use Audit's strategic locale in the organization to foment better overall security?

One of the main challenge with Audit is the "checkbox Olympics", long, unblinking Excel spreadsheets that do not appear to dovetail with security threats or capabilities. But with some analytical elbow grease, its possible to alligator wrestle Audit requirements into something that resembles a set security architecture capabilities that benefit your enterprise. The main analytical tool to do this is a Threat Model.

Let's take the much-maligned PCI DSS. No doubt the set of requirements in the standard would not be everyone's top 100 security controls. But that does not mean they are useless either. 

In fact, there is a fair amount of optionality to be found in the standard. That optionality grants the security architect some degree of latitude in how they can seek to answer certain requirements.

So a simple way to express security architecture capabilities in the context of a threat model is as follows: 

Threat	Sec Svc	Data	App	Channel
Spoofing	Authentication		SAML	TLS (one way)
Tampering	Integrity	SAML
Repudiation	Monitoring		Logging,  SIEM
Information Disclosure	Encryption, Hardened Interfaces, Defensive Data handling	SAML		TLS
Denial of Service	Availability
Elevation of Privilege	Authorization		RBAC, ABAC

One mistake made by infosec teams is that there is no single or set of security architecture views. That means the first time an end to end model is attempted is based off the Auditor's check boxes. If you do that, you do not end up with Sunday at the Park with George, you end up with a bizarre blizzard of random, disconnected dots. Like someone threw up all over your canvas.

Instead of the auditor's check boxes, the first cut is to define the current and potentially desired target state capabilities as above table shows. Then the Audit requirements get brought into the current/future capability context. 

Let's take an example with some illustrative entries from sections 3, 8 & 10 of PCI DSS. Map each requirements to the threat and potential types and locations of the defense. 

Threat	Sec Svc	Data	App	Channel
Spoofing	Authentication	8.1, 8.3	8.1, 8.3 SAML	8.1, 8.3 TLS (one way)
Tampering	Integrity	10.5 SAML	10.5
Repudiation	Monitoring	10.2, 10.5	10.2, 10.5 Logging,  SIEM
Information Disclosure	Encryption, Hardened Interfaces, Defensive Data handling	3.4 SAML	3.4	3.4 TLS
Denial of Service	Availability
Elevation of Privilege	Authorization		RBAC, ABAC

The result is a range of options - we can identify gaps, and find capabilities that are in place already or planned. This helps "tune" the security architecture by finding where to double down on existing efforts and harmonize previously disconnected security efforts.

Audit is viewed as subtractive, but like pointillism, there is opportunity to bring it all together: "Painting is inherently subtractive, but Pointillist colors often seem brighter than typical mixed subtractive colors. This may be partly because subtractive mixing of the pigments is avoided, and partly because some of the white canvas may be showing between the applied dots."

Don't let George the Auditor crush your security initiatives, let him help you. Its morning in infosec, time to pull on the boots, and get to work.

Top 10 API Security Considerations

Just released over at Axway, my new paper "Top 10 API Security Considerations". Mark O'Neill and I did a webinar on this together, and now the paper is available (free reg required). 

I see a lot of people rolling out APIs without a ton of thought given to the security fundamentals. This paper is designed to help you build a model that works to protect your APIs.

Here is a summary of the issues top 10 for API Security, you can read the paper for more examples.

1. Implement Model-Approach-Controller architecture

Information security is usually very focused on dealing with threats and vulnerabilities, and less aligned with architecture. A core principle of architecture is DRY (Don’t Repeat Yourself), which means that systems should be based on design patterns that allow for scalability and manageability.

2. Know and contain your assets

The basic mapping for access control is pretty simple. Subjects (like users and clients) request access to objects (like data, applications and services), and access controls mediate the decision to grant or deny access. However, this simple subject- request-object mapping quickly becomes complex when you factor in management considerations.

3. Design for malice

Most security architectures devote the lion’s share of attention and focus to access- control services that establish the rules of engagement for authenticating and authorizing users. But what about malicious actors that are focused on defeating the system? They often know the exact protocols of the access-control system and are deliberately trying to bypass it. Or, they are trying to exfiltrate data and other valuables from the enterprise.

4. Monitor for flaws — API attacks are happening

“You don’t know who’s swimming naked until the tide goes out.“ — Warren Buffett

Mobile security gets a lot of attention, and rightly so. But look at where the attacks are happening — on the server side. Apple’s recent challenges with iCloud are a great example of this. Apple users endured high-profile breaches even though their data was generated on iPhones, stored on the iCloud server and protected by passwords. The attackers were able to crack those passwords by using a brute-force cryptanalytic attack (continuously guessing password possibilities). According to Apple CEO Tim Cook, “Apple could have done more to make people aware of the dangers of hackers trying to target their accounts or the importance of creating stronger and safer passwords.”

5. Think mobile and beyond

The mobile computing age is upon us — at this writing, there are more mobile users (1.8 billion) than web browser users. Security in the mobile age is at least as much about server-side API security as it is about securing mobile devices.

Delivering security to a wide proliferation of different kinds of clients is a daunting task. There are tens of thousands of variants to consider just in the Android ecosystem alone.

The real challenge is to define where and how to centralize security policy enforcement. If you have 18,000 different devices, you don’t have a controllable system; you have a zoo. 

6. Think of sessions, not just APIs

Signing on to an API is one thing, but what about the second, third and nth call? Initial authentication differs from session authentication in that the latter is usually based on session keys. Session keys must be generated in such a way that they are not easily guessed; in practice, this means long and random identifiers. Session identifiers must be protected both in transit (for example, with TLS/SSL) and at rest, but securing a local sandbox for storing session identifiers is a major challenge today.

In addition, the API session is usually a “midstream” session. Consider a mobile application where a session is running on the client device, another is running between the client and the API gateway, and at least one more is running between the API gateway and the back end. Even in this simple example, at least three sessions fire up when the user presses thumb to glass. 

7. Simplify user experience

Users don’t care about the details of identity and security protocols; they just want to use the system. Unfortunately, the security industry has historically placed users at the center of the security protocol, and asked them to make intelligent (and technical) risk- based decisions by answering questions like, “Do you trust this certificate?” 

8. Simplify the developer experience

Developers are users, too. APIs can unwittingly create vulnerabilities by not arming them with sufficient knowledge. For example, a developer may hit an API too many times and degrade performance. Or a developer may not know why or how to protect API and session keys. These problems can result in Denial of Service, Privilege Escalation and other security issues. 

9. Appoint an API curator

This Top 10 list is primarily focused on technology, but even in the age of machines, we humans still play an important role (for at least a few more years, anyway). As much as tech matters, it’s important to get the organizational side right, too — just publishing APIs in a haphazard manner leads to chaos. Organizations need a gatekeeper who can ensure that policies and processes have been followed before exposing the API (and all the data and functionality behind it) to the outside world. 

10. Be bi-directional:Notifications, Websockets, SMS

Access-control paradigms are changing. Client/server communications mainly follow Request-Response models, but with mobile, multi-factor authentication and HTML5, we are starting to see wholly new protocols in use. 

**

In honor of Spinal Tap we took this top ten list to eleven, read the paper for the eleventh issue, full descriptions and examples. 

Analysis on data breaches and stock prices

Here is an interview with me on how stock prices perform post breach and what if anything we can glean from this. And here is my post on same topic at Securosis with some more analysis.

Does Progress Come From Security Products or Process?

How many times have you heard "Security is a process"? Say it often enough and it produces a certain Zen-like calm. But what does it mean, is it likely to happen or even achievable?

I have often wondered at the tremendous number of "silver bullet" efforts in the security industry. The first time I saw the trade show floor at RSA I was powerfully moved, and not in a good way, by the sheer number of people questing for the Seven Minute Abs approach to security. Most of the answers were not on the tradeshow floor, they are back at the home office, lurking in source code and the processes that built them. I wondered - security is a real problem, these people know this, so why were people here in San Fran talking to vendors about Bassomatics instead of back at work getting the job done? 

Turns out there is an answer - this is how pesky humans operate. Its situation normal. John Kay's recent column in the Financial Times Why do we welcome innovation to products more readily than to processes? is one that every security pro should read.

"Children love to play with new toys but hate disruption to their routines. These traits persist in adult life: innovation is readily adopted when it is incorporated in new gadgets but innovation that involves doing things differently is resisted.

Look around a university. At a super­ficial level, modern information technology has changed everything. Most activities — communication, scheduling and presentations — are conducted electronically. At a deeper level, nothing at all has changed. The course structures, materials and the methods of pedagogy remain essentially the same.

As Richard Nelson, the economist of innovation, has pointed out while American children are much healthier than they once were they are not much better at learning to read. Innovation that comes in a pill or injection is easily adopted: innovation that manages a process better is not.

It has always been so. Anaesthetics were developed in the mid-19th century and soon all surgeons were using them. However, when a Viennese physician discovered that the most important thing surgeons could do to keep their patients alive, especially those patients who were newborn infants, was to wash their hands, the profession resisted the innovation for half a century. While doctors would readily experiment with new chemicals, they fought any acknowledgment that their procedures were defective."

Again, go read the whole piece. 

You see security pros are engaged full time as change agents. Security processes are fundamentally new to most organizations. Companies are trying to go from Crawl to Walk to Run. Even if your company is crawling along in security, its trying to get to walk, these introduce major process changes. Do not underestimate the level of friction that process changes can incur.  Do not underestimate the amount of process engineering required to get the job done. The knock on effects of this are why most security programs fail to achieve their goals. Usually better to start with something simple like a checklist - must wash hands before deploying code to production.

One test that I like to use, is to see what is the most security value that you can create with the least amount of process change? The main reason I really like Gauntlt is that it does introduce a fundamentally new development process, instead its engineered to fit inside of existing development processes. Sure there are any number of other theoretically better SDLs out there than putting Gauntlt into Agile test cases, but Agile is how the hundreds of developers at your org are already building software. Will you be successful changing how they build software and rolling out new security mechanisms at the same time? Or is it better to find improvements near at hand, and embed security inside existing processes?

Process engineering is deeply unsexy. It is about as far removed from the glamour, fashion show world of security conferences as you can possibly imagine, but its where the actual changes occur.