Sep 23, 2014

The art of hardening is just more science


Alternate Title: I have some time and curiosity, how can I use it to improve my security?
Update:  Saw some articles that highlight the importance of hardening for Privacy so figured I would share.


I recently had the opportunity to revisit some of my earlier operational skills and and thought I'd shine a fresh light on something we've all been taught is right to do but may not know why.

Let's start with the opportunity. I had the opportunity to help design an achievable mobile architecture for deployment of SalesForce1 (SF1) on iPads. For more details, you'll have to attend our talk at Dreamforce in October titled: Securing the Salesforce1 Platform Mobile Workforce.

What I learned during this experience has helped me see more of the roots of what we do and made me look deeper into myself and my approach to security. Along the way I uncovered skills I hadn't been able to apply to the larger problem space of Security.   This was because of the path I had been given which lead to a dependence on the work of others. I also found a new appreciation for the science of security.

The focus of the rest of my noise today will be on hardening. I want to take you through the why, how, who and when and eventually lead to a series of entries that will take you through an experiment in hardening a Nexus 7 Android device.

Hardening defined

Hardening is a term we use a lot in security. It has a long history in military science probably originating alongside the science of tempering metals to make them harder and less likely to break during combat. Another term we get from the military that is sometimes used is fortify since we're often shoring up the defenses that architects and developers didn't build into their products so that solutions can better defend themselves. The term harden actually predates fortify in the English language according to Merriam-Webster so I'll stick to harden.

Hardening for Privacy

In our modern world, preventing breach and theft of personal or community resources is not the only driver to harden systems. Because of the pervasive nature of state and private sponsored monitoring there is also an aspect of hardening that applies to the output of an individual using a system they may or may not fully understand.

Prior to computing technologies, the equivalent of this leakage risk would have been thin walls that let the neighbors hear their neighbor's louder moments of joy, sadness or anger. In the modern world the creators of the tools we love to use are better trained in the science of measurement than ever. They use these skills and the technologies we love to buy to adapt their products at tremendous rates to keep pace with our changing interests so we buy more of their products. A primary concern for the Privacy Advocates is how this measurement happens. Since it is often via the devices we place on our persons, put our thoughts into and wholly depend on to maintain our pace of living, this edition will also cover hardening for privacy as well as reducing attackable surface area for our systems.

Examples:

Microsoft's Windows 10 Preview has permission to watch your every move
How to Control Your Privacy in Windows 8

How do we harden business processes and systems?

I thought about this and read some more on threat assessment and realized while there are many types of technical attacks, the mitigation strategies seem to fall into sets addressing three main goals.

  • Reduce – Eliminate opportunities to gain access to or monitor the system by disabling or removing opportunities (e.g. brick up doors, disable telnet, put the printer in a locked room, sanitize input to reduce injection of special characters, protect jargon or not publish information to minimize social engineering attacks, etc.) from the system or decrease the effectiveness of direct attacks by increasing the complexity of the direct attack needed to access the asset (e.g. failed password lockouts, QoS rate limiting, Captcha, penetration testing, access authorization procedures).
  • Restrict – Prevent access where access to the asset needs to be allowed for some by either controls that entirely limit the access or partially limit the access via authorization to bypass the controls that were deployed thus requiring indirect methods to achieve a successful attack.
  • Respond – Deploy defensive forces (e.g. IPS, WAF, SOC, forensic tools) and properly support their ability to react (e.g. logs, procedures, authority to act) to any successful breach in order to reduce the magnitude of resources lost by a successful attack.

How do we find the right balance?

After you have an understanding of the business process there are many techniques you can use to get to recommendation for mitigating the risks your management will care most about. I want to only touch on the most common here since my real message is the process I went through to harden the Nexus 7 and blog entries are a shorter format because you don't have a lot of time to spare.

Threat Assessment

Threat assessment is the execution of thoughtful and technical activities to identify the most likely attackers and techniques that could be employed against the solution you're designing or deploying.

Threat Assessments can consider both known and unknown attack vectors although most environments can only afford to address the known vectors in hopes of addressing the majority of attackers. Unfortunately this approach has produced attack methodologies that are working around the available tools. This is driving us out of necessity to focus more on response since we can't keep up.

Known attacks and countermeasures

Evaluating threats using known attack methods are commonly driven by tools since we all know that it is not in our best interest to re-invent the wheel if we really want to get anything done.

Examples of tools to identify new threats and risks are:
  • Configuration and practices audits
  • Industry best practice configuration guides
  • Patch service monitoring
  • Customized build guides
  • Industry and regulatory standards and practices
  • Signature based filtering tools (e.g. anti-virus, WAF, IDS/IPS, Firewalls, pattern matching log analysis, static code analysis tools, low end penetration testers and testing tools)

Although these tools rarely take a structured approach to identifying the attacker or the probability and capability of anyone every wanting to attack the asset, they do provide a higher ROI for the cost. The cost savings comes from the resources needed to delivery via manual or automated means. Unfortunately, this level of assessment is deemed adequate by many regulators so long as they are part of a structured risk assessment exercise that performs analysis on the results in the context of threats that are unique to the environment and the business' goals to produce some reasonable and comprehensive recommendations for improvement.

Since there is a tremendous ROI for these methods, they are often launched against existing environments with existing vulnerabilities that may have been appropriate at the time the system was created and may still be appropriate to management's risk tolerance. However, these tools, techniques and resources provide the most return on new environments. On existing environments application of these tools without additional thought exercises and planning often leads to significant contention between the designers/developers and security resources given their conflicting views on the risk-reward of each desired capability with it's opposing mitigation. Since these tools are being applied to address a common threats this approach can make cost justifying contentious positions more difficult because of the lack of probabilities that management can understand over the “expertise” of the security staff which amounts to “trust me, it's the right thing to do” making the security only as good as the experience of the staff that management was smart enough to hire combined with the output available from their tools and vendors.


Unknown and high probability attacks and countermeasures

When thought exercises and other dynamic techniques are applied in conjunction with the static tools the cost for the solution goes up and the effectiveness rises. The good news is that the overall cost tends can balance out because the degree of contention reduces which saves on design and implementation costs. A strong resource capable of applying the lessons learned from longer experience against an established business process and security solution can both raise the awareness of the management, designers, developers and support to the most likely threats they face. This will help the business sustain a more robust security solution that will continue to identify the most relevant residual risks that exceed management's tolerance to deploy the most optimal solution to solve new problems and so on and so on.

Examples of dynamic techniques besides thought exercises are:

  • Heuristic tools (e.g. anti-virus, next gen security appliances for deep analysis and blocking/alerting, dynamic code analysis, ethical hacking by high end penetration testers, honey pots, threat assessment services)
  • Fuzzing tools which inject static and non-static information into key components of the system to attempt to achieve unanticipated results
  • Reverse engineering including simple experimentation – This is where I want to focus because it starts with minimal knowledge of the system, some tools and general or extensive knowledge of computers and just explores an established solution to identify new ways to configure or abuse the features that are available to gain access to the assets it protects. This is the approach I took to analyzing the iPad platform we designed for the work project and the approach I took to achieve the configuration described in the second installment of this article.
Note: Experimentation can combine all the other methods but also brings to the forefront the scientific method used by hackers. Back in the early days of computing this was the way the early hackers got anywhere.   It's also why we have computers in the first place and why there is a difference between hackers and crackers.  Hacking goes back way before computers if you take the definition to its fullest interpretation.    FWIW, I think we need to think beyond the definition posted on Wikipedia to include other forms of hacking if we're to beat the crackers. A cracker is someone who puts together what others have done to achieve a goal (usually a negative goal) while a hacker is someone who just needs some knowledge of computers, time and curiosity to understand a system well enough to find new ways to use it to break features or use features in a new way even including security features. To see the difference, think of someone building a radio from a manual and possibly improving it slightly by putting things together in different ways (a cracker) as compared to someone understanding electricity and harmonics enough to design and build both a means of controlling the output of a system sufficiently to produce organized and precise output and another system capable of collecting and processing that output and converting it to a physical vibration capable of being heard by the human ear (hacker).

Wrapping up and delivering

I've talked today mostly about the ways that threat and risk assessments can be performed at a macro level. These ideas and strategies need to be adapted to your situation and incorporated into an overall enterprise-wide security risk management strategy.

Not all of the strategies will work in your organization or are possible in the budget you have at your disposal. Many of these strategies can often identify more issues than can be handled by an organization so it's critical to measure often and plan to evolve your prioritization approaches or you'll likely be told not to try to “boil the ocean” and be seen as an overachiever or worse, have your control become ineffective and/or you labeled a wrong fit for the organization.


Thanks for your moments and see you next time...Hardening Android - Preparing your soul.

No comments:

Post a Comment