Hardening Android (a measurable intermission)

Alternate title: Don't throw the baby out with the bathwater.

As we dive into the next phase of our understanding of the platform I think we need to shed some light on another commonly confusing word often used by people inside the security community and out.  The word is Impact.

When we in security think of impact we often think of the worst possible thing that could happen in our early stages.  After a while we learn to think about the most probable too and eventually we strive to consider the spectrum of possibilities.  But this still leaves out one side of the impact that is essential to us successfully fitting into a multi-disciplined team working to achieve a business goal. That is the sense of end-user impact. End user impact is often the single most determining factor in whether a security control gets funded and implemented vs. just proposed. Knowing the impact your proposed mitigation will have on the most relevant business goals will help you recognize when you are helping or hampering the team.

So let's explore the term a bit...

First, a statement of direction to set the mood: Never get lost thinking that compliance with policies is a business goal. It is a secondary goal. Good security doesn't need policies to keep the bad guys out. People need policies to remind them to do the details of security so they don't get in trouble when the auditors come by for skipping on the important stuff that eventually turns into the chink in the armor that lets the sword through.

So what was the impact on your thinking there? Did it change your mind? Did you agree so it had no effect? Did it blow your mind? The point of this was to highlight that the degree of impact depends on your perspective.

The perspective challenge is a problem I've covered earlier so I won't propose any fixes here but I encourage you to go back and read this and this and this for more context before you write me a note to have a debate.

Now that we have the perspective problem out of the way let's talk about measurement. We've all heard the saying something like “What is measured gets done.” So how we measure impact depends on the goals we want to achieve because an impact is a positive or negative movement towards that goal. So who makes the goals in your business? It's certainly not you—after all, you're securing the resources that are used to make the money, not directly making the money.  Frankly, it doesn't really matter for my purpose today. Don't get me wrong. It does matter beyond measure when I'm at work.  I can't find the right impact to focus on without knowing precisely what the businesses' pain points are with confidentiality, integrity and availability. For the purposes of a thought exercise trying to determine an optimal hardened posture for any system the factor of impact you want to measure most is time.

Why time? Time is the most precious resource to both the attacker and business user. The attacker is trying to get in and out before the odds catch up to him/her getting them caught. The business user is trying to get as much done toward today's and tomorrow's goals before going doing what they work in order to be able to do.

Our job is to deploy the right control that increases the time required to exploit a vulnerability for the attacker while minimizing the impact on the business user's available time budget for the day.

So for the assessment of a control's benefit to the hardened system I am going to identify a semi-qualitative rating for the time factor from both the end user's perspective and the attackers.

For an example let's consider the relative impact of a setting of 5 failed logins before the user gets locked out.

For the user who knows the password, the impact is not even noticeable within their daily habit until they return from vacation and can't remember if the password is the same as their Gmail or their Facebook account. So we'll rate this as a 1 on a 5 scale. However the attacker would be highly impacted because they would have to invest a lot of time (days) to try to understand the user account owner well enough to guess 5 most likely passwords OR try multiple guesses hoping to get lucky because the user might be lazy (e.g. Password1, P@ss102014 because we know they just got back from vacation and were likely locked out) from a location that is unlikely to be the usual source which increases the possibility of tripping an effective monitor solution (e.g. IDS, SIEM, etc.).

With this scale in mind, I will assess the impact of implementing the features that Google has given us so we will have a foundation to build a business case for or against the control for our particular use case.

One last note: I will not be contrasting controls to identify compounding, conflicting or compensating value in terms of time. That is a topic for another day.