Context: We have Security Champions at the BBC! The idea is that we’re embedded in teams and can help people think and talk about security before it gets to any official Infosec/Pen testing phase #ShiftLeft.
The issue is it’s a very code/dev focused group of folk, and we want to try and see if we can start a bit of a culture shift to get everyone thinking about security, including (in our dept’s case) product owners/BAs/Project managers/UX.
I have some ideas on how to drive these conversations and get people to realise that security isn’t just a code issue, but everyone can contribute to these discusssions (I’m thinking things like using some risk storming resources, for example) but was wondering if anyone has gone through something similar and had some ideas or things they’ve learned for this kind of thing?
I’m slowly trying to introduce some security concepts such as
Threat Modelling
# What is Threat Modelling?
A threat model is essentially a structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through security glasses.
Threat modelling is a process for capturing, organising, and analysing all of this information. Threat modelling enables informed decision-making about application security risk. In addition to producing a model, typical threat modelling efforts also produce a prioritised list of security improvements to the concept, requirements, design, or implementation.
Although the overall implementation of the Rules Manager is an internal tool, it still has various routes into the application from third party sources (Charles River Development), REST API's via the Gateway and even from systems such as the Active Directory.
Most of the time, a threat model includes:
* A description / design / model of what you’re worried about
* A list of assumptions that can be checked or challenged in the future as the threat landscape changes
* A list of potential threats to the system
* A list of actions to be taken for each threat
* A way of validating the model and threats, and verification of success of actions taken
# Why
The inclusion of threat modelling in the SDLC can help
* Build a secure design
* Efficient investment of resources; appropriately prioritize security, development, and other tasks
* Bring Security and Development together to collaborate on a shared understanding, informing development of the system
* Identify threats and compliance requirements, and evaluate their risk
* Define and build required controls.
* Balance risks, controls, and usability
* Identify where building a control is unnecessary, based on acceptable risk
* Document threats and mitigation
* Ensure business requirements (or goals) are adequately protected in the face of a malicious actor, accidents, or other causes of impact
* Identification of security test cases / security test scenarios to test the security requirements
# 4 Questions
Most threat model methodologies answer one or more of the following questions in the technical steps which they follow:
### 1. What are we building?
As a starting point you need to define the scope of the Threat Model. To do that you need to understand the application you are building, examples of helpful techniques are:
* Architecture diagrams
* Dataflow transitions
* Data classifications
* You will also need to gather people from different roles with sufficient technical and risk awareness to agree on the framework to be used during the Threat Modelling exercise.
### 2. What can go wrong?
This is a "research" activity in which you want to find the main threats that apply to your application. There are many ways to approach the question, including brainstorming or using a structure to help think it through. Structures that can help include STRIDE, Kill Chains, CAPEC and others.
### 3. What are we going to do about that?
In this phase you turn your findings into specific actions.
### 4. Did we do a good enough job?
Finally, carry out a retrospective activity over the work you have done to check quality, feasibility, progress, and/or planning.
* The OWASP Cheat Sheet goes into more detail (https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html). For the Nexus Risk Management System, periodic reviews of the service will be documented in the various child pages.
A good resource that I’m treating as a bible is a series of articles by Tanya (shehackspurple)
I’m a newbie, but I’m trying to learn more about app security and try and think about these concepts as early as possible. I think if nothing is implemented, at least the awareness of security has been raised. It’s good to make the PO’s and BA’s think about the Non Functional aspects of the software. It raises the game for everyone IMO.
In my organization, it is also kinda the same. Me and some of my colleagues are trying to break the myth that "Security is not only about code"but it is a mindset. Currentlly we have started hosting CTFs and meetups which are practical based and can be attended both by techies and non techies.
We have quite a good security framework in place in our organization for IT security, but people do not know about it and fail to appreciate it.Me and my colleagues are organizing more sessions and bootcamp where we explain security in lay man’s terms.
@gemma.hill1987 - Security is a subject I’m mildly passionate about. The root of any Security based practice is user training.
User Education - critical to any security awareness policy is getting people informed about the ploys bad actors use to gain access to your informaiton; the InfoSec Triad (confidentiality, integrity, availability) is at the heart of any Security program.
Social Engineering - another critical part to user education is knowing how to spot and avoid fake websites, emails, and malicious links; know what phishing is.
Attack Vectors - its important to know how your mobile device, a random website, even the wifi at a local cafe can be used to gain access to your computer or mobile device and do serious damage.
I could go on, but you get the idea. And this is all before introducing things like hacking, code injections, click-jacking, and privilege-escalation (to name a few).
We are looking to purchase an Interactive Application Security software to be used as we do manual testing. The QA Team currently uses a SAST tool to identify vulnerabilities and report to the teams