Archive

Archive for the ‘Strategy’ Category

Top Technical Mitigation Strategies (from the Australian DSD)

June 2, 2015 Comments off

There are few solid pieces of empirical evidence on what works in security. The Australian Defense Signals Directorate (DSD) Strategies to Mitigate Targeted Cyber Intrusions is one of those. We at Stratigos Security think a lot of what they do. So does just about everybody else who has come into contact with the documentation.

This post examines some of the assumptions, implications, and a conceptual framework to better understand the document. Let’s start with some of the stated background and assumptions.

  • Investigation based – That the mitigations are a result of analysis of investigations carried out by the DSD, primarily in the government sector.
  • Adversary focused – That the mitigations are meant to counter adversarial attack.
  • Targeted attacks – That the adversaries are motivated to target the victim organization, specifically.
  • High value information – That the adversaries’ objective is to steal intellectual property, national defense secrets, or other highly sensitive documents.
  • Exhaustive application of mitigations – That mitigations will be applied to 100% of systems, not just a subset.

There are 35 total mitigations listed, almost all of which are specific technical controls. At Stratigos Security we tend to like to bundle technical controls into a higher level framework. This is more digestible for our clients, and allows for a better understanding of why these mitigations work. That’s the key to long-term success in design, implementation, operation, and maintenance of a security program.

Stratigos has aligned most of these mitigations into a few core objectives. In doing so, we seek to harmonize them so each builds on the others. The set works together much better than the sum of each of the individual ones. Our objectives are as follows, as well as examples of mitigations from the DSD document.

  1. Execute only trusted code – Authorized software packages, components, and functions are defined and enforced.
    • Whitelisting
    • User application configuration hardening
    • Restrict administrative privilege
    • Workstation and server configuration management
  2. Ensure code is trustworthy – Software is free from known defects.
    • Patch applications
    • Patch Operating System vulnerabilities
  3. Ensure trusted input – Information and commands are legitimate, meaningful, and non-malicious.
    • Host and network firewall
    • Email and web content filtering
    • Education and awareness
  4. Manage access – Access proceeds only through known mechanisms, which validate authorization and identity.
    • Multi-factor authentication
    • Enforce a strong passphrase policy
  5. Contain failure – Security failures in one system or network segment do not affect other systems or segments.
    • Network segregation and segmentation
    • Anti-Virus
    • Host and network IPS
    • Operating System generic exploit mitigation
  6. Eliminate anomalies – Causes of unknown and unexpected events are identified and eliminated, as appropriate.
    • Logging of successful and failed system events
    • Logging of successful and failed network events
    • Capture network traffic

Astute readers will notice that there is a large gap between the objectives and the underlying mitigations. The mitigations are tools, or supporting technologies, that help achieve the objectives, but they do not ensure the objectives will be achieved. This underscores one of the major mistakes most organizations make when they go to implement such a set of mitigations. It’s worth going back to the background and assumptions and identify some of their consequences. Of course this is far from an exhaustive list.

  • Limited applicability – These mitigations come from investigations of Australian government organizations. Other organizations may have different experiences.
  • Accidents are excluded – Security risks which result not from adversarial attack, but from accidents are not included. (One of the most common is data breach caused by theft or loss of a mobile device, laptop, or backup tape.)
  • Mobile devices are specifically excluded – The mitigations apply to workstations and servers, but not to mobile devices.
  • Governance, process, personnel are poorly covered – The mitigations do not include non-technical approaches, which can significantly affect security, risk, and cost.
  • Alternate risk mitigation – Risk mitigations available to corporate entities – such as insurance – are not available.
  • Cost considerations – Corporations typically require some measure of value justification, associating costs and risks to profitability, rather than to national security or human life.
  • Impacts – Impacts should be analyzed in the context of the specific solution in the proposed environment.
  • Implementation quality – Poor implementation of the mitigations would result in reduced effectiveness.
  • Implementation completeness – Implementing mitigations to fewer than 100% of systems would change effectiveness and cost estimates.

Knowledge of the underlying assumptions, their consequences, and unstated assumptions is key to implementing them appropriately. You can only fill in the missing pieces when you recognize they exist, and where. Some of these missing pieces can help you greatly reduce cost, not just add more to the shopping list.

But we’re diverging from the point here. These six objectives are not the only ones that can be derived from the Australian DSD’s guidance. They have worked for our clients and they allow a fairly complete mapping to the 35 mitigations. This superset also naturally aligns to strategic initiatives to develop processes to take full advantage of these tools. Maybe we’ll add more on that in a future post.

Can you be too secure?

July 31, 2014 Comments off

When I hear someone say “you can never be too secure,” I assume they don’t understand the implications of that statement. Perfect security can be seen as the absence of risk. This sounds like a tradeoff most people will want. But that’s not always the case. In fact in most business that’s the opposite of what you really want.

Risk is at the heart of the capitalist system. Without risk there is either no room for profit except through exploitation and collision. So businesses must take risks. If there were no risk competitors could easily enter the market and disrupt the industry.

So risk is necessary; risk is good. There is value in risk just as there is in security. Understanding and undertaking smart risks allows you to balance concerns with ambitions. Balance gives health; imbalance can lead to total collapse.