Introduction Into CyberSecurity Training by Bruce Williams


I have been often asked about cybersecurity training. Where do you start? Websites like these are a good

To train people in cybersecurity there are various approaches. The method which I teach is based on a risk/return which tries to defend a small to medium business against web attack. One size will not fit all, so to train people the target competencies must be understood.

Definition of cybersecurity

The preservation of the confidentiality, integrity and availability of information

ISO/IEC 27000:2012

Standard follow the Plan, Do, Check Act cycle


As Risk=Likelihood*Impact we turn to threat modelling

The concept of threat modelling is not new but there has been a clear mindset change in recent years. Modern threat modelling looks at a system from a potential attacker’s perspective, as opposed to a defender’s viewpoint.

Microsoft have been strong advocates of the process over the past number of years. They have made threat modelling a core component of their SDLC, which they claim to be one of the reasons for the increased security of their products in recent years.  

I like the explanation below

Threat Modelling

The most common secure software design practice used across SAFECode members is Threat Modelling, a design-time conceptual exercise where a system’s dataflow is analyzed to find security vulnerabilities and identify ways they may be exploited. Threat Modelling is sometimes referred to as “Threat Analysis” or “Risk Analysis.”

The process of Threat Modelling begins with the identification of possible and commonly occurring threats. Different practitioners have adopted different approaches to the task of enumerating threats against the design being analyzed:

  • “STRIDE” – this methodology classifies threats into 6 groups: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege. Threat Modelling is executed by looking at each component of the system and determines if any threats that fall into these categories exist for that component and its relationships to the rest of the system.
  • “Misuse cases” – The employment of misuse cases helps drive the understanding of how attackers might attack a system. These cases should be derived from the requirements of the system, and illustrate ways in which protective measures could be bypassed, or areas where there are none. For example, a misuse case involving authentication would state “By successively entering login names, an attacker can harvest information regarding the validity (or not) of such login names.”
  • “Brainstorming” – if an organization does not have expertise in building threat models,

having a security-oriented discussion where the designers and architects evaluate the system is better than not considering potential application weaknesses at all. Such “brainstorming” should not be considered a complete solution, and should only serve as a stepping stone to a more robust Threat Modelling exercise.

  • “Threat library” – a format that makes threat identification more accessible to non-security professionals. Such a library must be open to changes to ensure it reflects the evolving nature of threats. Publicly available efforts like CWE (Common Weakness Enumeration—a dictionary of software weakness types), OWASP (Open Web Application Security Project) Top Ten and CAPEC (Common Attack Pattern Enumeration and Classification that describes common methods of exploiting software) can be used to help build this library. Use of a Threat library can be a quick way to take advantage of industry security knowledge (helping teams that lack sufficient knowledge themselves) or combine elements of other Threat Modelling methods (such as linking a threat to misuse cases and a STRIDE classification).


OWASP Threat Library

Perform Penetration Testing

The goal of penetration testing is to break the system by applying testing techniques usually employed by attackers, either manually or by using attack tools. Penetration testing is a valuable tool for discovering vulnerabilities that reside in the system’s business logic. High-level business logic aspects are often hard to detect from the code level.

However, it is important to realize that a penetration test cannot make up for an insecure design or poor development and testing practice

Fundamental Practices for Secure Software Development


A Guide to the Most Effective Secure Development Practices in Use Today

February 8, 2011


I have written various articles about pen testing in 2016. These are

Pen Testing The Red Queen Effect

On critical points Audit of cybersecurity critical points

Pen test tool shootout

These articles are from a pen testing approach. They have appeared in PenTest Magazine.

There are more recent articles on a testbed using OWASP and OneHost Cloud which are

Pentest Magazine OneHost Cloud


PS The size of an organization also determines what type of standards to adopt and y. In relatively small establishments, the ease of implementation and running of the system  influence the standards to be used

Examples include:

Homeland National Security  Awareness

Standard ISO27001:2013 (replaced BS 7799) – outlines a code of practice for information security management that further helps determine how to secure network systems.