The Genesis of an Asset

When we look back at data breaches that have plagued most industries over the past few years we see that the adversaries, threat actors or cyber criminals are able to capitalize on weaknesses and flaws in computing by exploiting design and implementation flaws within technologies. Many organizations respond on a whim to mitigate these challenges (perhaps caused by fear or doubt) by throwing more money at technical solutions that they have been promised to be the silver bullet.

Obviously this is another common weakness, the knee jerk reaction of responding to the problem by adding an additional layer of security technology without first understanding the root cause or without answering the following questions:

• What were their goals and motivations?
• What were their tactics, techniques and procedures (TTPs)?
• When, why and how did this happened?
• Where was this highly valued information stored?

To mitigate the risks of the increased costs that might ensue from a data breach we need to work towards going beyond the concept that adding a new security layer will avoid being compromised next time.

Likewise, it is also widely accepted that to design and maintain a secure system without relying on these additional security technologies is a complex problem; to gauge the level of resilience of an attack or even determine the necessary countermeasures for limiting and reducing the associated risks of a system, it requires a deep knowledge of the environment and a multi-disciplinary approach. This approach needs to concentrate the effort across three disciplines: Development, Operations and Security (known as DevSecOps). These new teams, in enterprise organizations, that should be strictly tied one with the other and having as final objective to develop the code, maintain the operations and secure organization’s critical assets and business systems.

To be able to claim the security of a system and working toward 100% of the risk acceptance by the organization, it is important always to recognize what are the types of threats the asset faces and measure the threat level of the system, identifying what must not be allowed to happen (security requirements) and what must happen (system requirements). So, the big picture of the definition of the system and security requirements is capturing the misuse, use and mitigation cases.

For the security team, provide proper direction to a risk-based scoring system and reduce the ability for the attacker to abuse it – is only possible with a realistic, deep and meaningful understand and review of the:

• Asset’s components and interfaces
• Network and application layers
• Data flow, trust levels and segregation between each components
• Entry/Exit points within the asset
• External dependencies and libraries the components rely on and may lead to security concerns

And finally, it is required to look at the asset using a threat-driven approach depicting the misuse cases for each single component.

Decompose and analyze the asset firsts, figure out the way in which adversaries work and the TTPs used will help the security team and the asset owner to answer from whom the system should be protected and from what and why.

The failure to make this analysis and fail to answer the initial questions can easily lead to a scenario where security controls fail to protect the asset’s value.

Security teams need to provide guidance in design and maintenance of the asset and, most important, provide reliability of the security measures taken to protect it.

The post The Genesis of an Asset appeared first on Speaking of Security - The RSA Blog and Podcast.