_This was extracted from our internal documentation and published as part of [our June 2023 internal cybersecurity course](https://bluedot.org/blog/internal-cybersecurity-2023/). I've left some comments from our session plan document when we went through the course._

## Session 1

### Opening

**Purpose and intended outcomes**

- State high level course structure
    - This week: discussing how to use technology securely.
    - Next week: how to build new technology products securely.
- State class goals (the most critical topics as recommended by the NCSC and EV's external cybersecurity consultants)
    - Know the importance of security to our work
    - Know that they are ultimately responsible for security
    - Contribute to discussions around security culture
    - Generate and store secure passwords
    - Use password managers and 2-step verification to mitigate phishing attacks
    - Identify and appropriately report security incidents, such as attempted phishing
- [from pre-course survey] Specific individual goals, or areas where people are uncertain about cybersecurity?
    - Password management
    - API security
    - How specific exploits work

**Resources**

- ⌛2:00 Indiviudal brainstorm: Did you manage to complete the mandatory readings? What did you find interesting / surprising / unclear / irrelevant / novel?
- [Participant]
    - I found the instruction to "email [security contact] if you get a phishing email" very useful, and cool that we have a place to do this
    - Also found the browser security settings helpful
    - I liked the NCSC exercise
- [Participant]
    - I really enjoyed your [page on browser security](https://bluedot.org/blog/internal-cybersecurity-2023-device-security/)
    - I wasn't aware of the [prankster](https://www.cybsafe.com/blog/the-true-story-of-a-prank-so-good-even-the-white-house-fell-for-it/) who phished the CEOs of Barclays, Goldman, White House staffers etc.
- [Participant]
    - All the special browser options that exist were cool - now I feel extra safe
- [Participant]
    - Instructions were clear didn't know there was a built in harddrive encryption thing on my laptop
    - I have my doubts about password managers and saving my password to my browser
- [Participant]
    - The browser security exercise was really helpful - most of my settings weren't aligned with recommended measures lol
- ⌛5:00 (shorter/longer as required) Discuss readings

### Exploration

**Activity 1: Brainstorming risks**

LOs: Know the importance of security to our work, Know that they are ultimately responsible for security, Contribute to discussions around security culture

- ⌛3:00 Brainstorm: What cybersecurity risks could materialize in or near the parts of BlueDot Impact you work on? What harms could these cause, e.g. the effects to BlueDot Impact, our customers, the wider ecosystem etc.?
- [Participant]
    - Social engineering attack that intercepts emails with funders and somehow redirects our funding to them. This would be bad
    - Private meeting notes or other private documents could be accidentally made public or less private, and those could then be visible to unintended individuals
    - Bad actors could hack our zoom systems and attend our meetings, and do bad things. This has happened to be me once at EA Cambridge where a group of people attended an online public speaker event and trolled it
    - Airtable, notion, google etc. are hacked
- [Participant]
    - Airtable
    - Participant/facilitator data
        - Demographic/affinity group data that they might ot want displayed publicly
        - Career plan data
        - Coaching call data - can get quite personal
    - Notion
    - Meeting notes
    - Tasks
    - Slack
    - Bubble
    - Email
- [Participant]
    - I share a lot of participant data with orgs. Employers may get to see their employees' responses to things! That's not ideal.
    - At the moment, there are a few links which give edit access to your data just with the link (no password) - this could cause small-scale accidental data breaches if a participant shared their link, but I think it's hard to do it maliciously.
- [Participant]
    - I can sign in as any user in the database which is useful for debugging but not sure what this says about how secure the logins are.
    - Logging into a person's account allows them to see all the information the user would see on Bubble so whatever they input to connect and reading completions and exercise responses.
- [Participant]
    - Participants' information from Airtable and Course Hub is hacked
    - Our Notion databases? I think a lot of Notion's privacy settings can be confusing and you can easily forget which links are public - some kind of regular audit of this would be good
    - Customer.io also has participant info so checking that it's secured
    - Public google docs if any in the company drive
    - Slack access for people who aren't active in the community anymore is another thing we should be looking into - not impossible (and probably easy) for someone to share participant or course data from our Slack externally.

**Activity 2: Passwords and 2-step verification**

LOs: Generate and store secure passwords, Use password managers and 2-step verification to mitigate phishing attacks, Identify and appropriately report security incidents, such as attempted phishing

- ⌛15:00 [NCSC exercise in a box](https://www.ncsc.gov.uk/section/exercise-in-a-box/using-passwords)
- Go through each question round-robin. Anyone can chime in extra ideas throughout.
- Further discussion questions:
- How should you choose a password for unlocking 1Password? Why might this be a better method than other common strategies?
- How should you choose a password for most other sites?
- Discuss [security culture](https://www.ncsc.gov.uk/blog-post/growing-positive-security-cultures)
    - Reporting when security things aren't working, so we can fix them to avoid bigger problems (e.g. workarounds for security problems like lengthy authentication, lacking equipment, buggy software)
    - Not blaming people for security failures, taking it as a learning opportunity
    - Importance of reporting suspicious events in preventing an attack, immunizing the whole organization
    - Discussing the [phishing funnel](https://www.ncsc.gov.uk/files/multi-layered-phishing-mitigations-infographic.pdf) as example

### Closing

**Exit ticket**

_[This was a Google Form]_

If you could only do one, which would you choose and why:

1. different but semi-weak (e.g. 'ponds2023') passwords everywhere
2. strong but same password everywhere (e.g. 'W!L\*e8.MdqvG2vgByUuP2hap@Ygn8H3b')
3. weak (e.g. 'orange') and same password but with 2-step verification everywhere

There's no wrong answer: this is about the thought process and being able to make and explain decisions about security trade-offs now that you understand the 'why' behind these decisions.

I will share my thoughts on these next session.

**Feedback**

- What's something you enjoyed or appreciated? E.g. something from the resources, a contribution by a particular participant, a technique used by the facilitator, etc.
- What didn't go so well from this session for you?
- How was the content? (too easy to too difficult)
- How was the delivery? (too slow to too fast)
- How did this compare to your expectations (worse to better)
- Was there anything about the content that you're still unsure about?

## Session 1 extras

### Demo: Intercepting HTTP

- Show differences in Wireshark when visiting [this HTTP page](http://wellbeing.uw.edu/topic/mental-health/) with the HTTP option enabled/disabled.
- Explain that this could be seen by many people, by showing the hops via traceroute wellbeing.uw.edu

### Activity: Phishing

LOs: Use password managers and 2-step verification to mitigate phishing attacks, Identify and appropriately report security incidents, such as attempted phishing

- ⌛5:00 Brainstorm: What makes a good (in terms of successful) or bad phishing campaign? Think about phishing campaigns you've heard of before, or maybe think about a time when you nearly fell (or did fall) for phishing, and times you immediately spotted it. If you have time, provide a concrete example of how the tactic was used.
- ⌛10:00 Build your own phishing campaign: Choose a target, and then plan out a phishing campaign that you think would be effective at them to do something they shouldn't do (e.g. give out information, transfer money). Try to use some of the techniques identified above.
- ⌛5:00 (2.5 mins each) In pairs, review each other's phishing campaigns. Comment on what you think is particularly clever about the techniques they've used. If time, suggest what other things could be added to make the phishing campaign even more effective.

## Session 2

### Opening

**Purpose and intended outcomes**

- State class goals (the most critical topics as recommended by the NCSC, OWASP and Microsoft)
- Identify when a security risk assessment may be needed in their day-to-day roles
- Perform a security risk assessment based on a threat modeling process
- Understand and be able to apply models to threat modeling including:
    - Identification: CIA triad or STRIDE; and
    - Prioritization: DREAD or FMEA
- Identify the most likely risks in a threat modeling identification process, including:
    - Broken authentication
    - Broken authorisation
    - Injection attacks
    - Insecure design
    - Vulnerable and outdated components
    - Overly permissive RBAC
    - Security logging and monitoring failures
- Address security risks identified in risk assessments

**Resources**

- ⌛2:00 Brainstorm: Did you manage to complete the mandatory readings? What did you find interesting / surprising / unclear / irrelevant / novel?
- Summarizing the readings

### Exploration

**Activity 1** ⌛5:00

- In pairs, explain the CIA and STRIDE models to each other
- Discuss the examples you came up with
- Discuss how the models relate: e.g. where do they overlap?

**Activity 2** ⌛20:00 This is a rough summary of the British Airways (BA) attack that happened in 2018. Speculative parts mean that the investigators were never able to figure out but narrowed it down to some options, or are parts which were redacted but security researchers guess were most likely.

1. The attacker got the login credentials (username/password) of 5 different 'Swissport' airport ground staff. Speculative: some passwords were guessed, and others were handed over when someone called the staff.
2. The attacker could login with these credentials remotely and gained access to applications related to Swissport's contract with BA.
3. BA used a tool called Citrix so people could access only specific applications. Unfortunately, it was misconfigured and as such the attacker was able to run custom applications that could scan the network for other servers.
4. During this scanning, they found an unencrypted file sharing server that everyone within the BA network had full access to. This server contained a plain text file which held the domain admin's username and password. A domain admin is one of the most privileged accounts available on Microsoft Active Directory (similar to a super admin in our Google Workspace).
5. By using these credentials, they were able to view other people's files. They were then able to find several database admin's usernames and passwords (speculative: in another set of files that shouldn't have been there in the BA network).
6. Some of these passwords were outdated, and there were several failed login attempts. However, this didn't set off any alarms. and the attacker eventually successfully logged in.
7. The attacker then had full access to almost all systems. They found the system logs, which had been recording full card details for the last 3 years by accident due to a misconfiguration intended to be only enabled while testing that had not been turned off. The data was not encrypted due to human error while setting up the server, and it was never reviewed.
8. The attacker then also was able to edit the British Airways website. They edited the website so that any card details entered would also be sent to their API, without disrupting the general payment flow. The website had not been configured with security best practices (e.g. a CSP policy) so data could be sent out to arbitrary APIs (although this might not have mattered given the attacker's access at this stage).
9. A curious member of the public noticed information being sent to this weird domain during the checkout flow. They reported it to BA, who managed to fix the website and then started working on removing the attackers from their systems.

In your small groups:

- Discuss what elements of the CIA/STRIDE models were compromised here
- Identify what from session 1 would have mitigated this attack
- Suggest other measures BA could have taken to improve their security here

**Activity 3** ⌛20:00

- Demonstrate how to use the [Chrome network tab](https://developer.chrome.com/docs/devtools/network)
- Give people a go at attacking the vulnerable bubble app: a custom-built capture the flag using Airtable, MiniExtensions and Bubble
- There are two hidden CTF codewords, of the format $ctf:code-word$
- You can also add a new job and edit people listed on the directory
- Hint: Login doesn't work, but sign up might

_[We haven't published this app. You could try other CTFs, like those by [TryHackMe](https://tryhackme.com/) or [OverTheWire](https://overthewire.org/wargames/)]_

### **Closing**

**Exit ticket** _[This was a Google Form]_

[Roll a 6-sided dice!](https://www.google.com/search?q=roll+6+sided+dice) Based on the number you got, your threat areas are:
1. Confidentiality and repudiation
2. Integrity and elevation of privilege
3. Tampering and information disclosure
4. Denial of service and integrity
5. Spoofing and confidentiality
6. Availability and elevation of privilege

[Roll a 4-sided dice!](https://www.google.com/search?q=roll+4+sided+dice) Based on the number you got, your system is:
1. Airtable
2. Bubble
3. MiniExtensions
4. Email

Describe a hypothetical threat that involves the threat areas and the system you got selected above.

For example, if you were given 'spoofing' and 'denial of service' on 'Email' your threat could be 'A phishing email get set to our staff pretending to be from our fiscal sponsor (Spoofing). It tricks someone into adding an attacker to our Google Workspace plan. Once inside, the attacker uses the account to send lots of spam, and so Google suspends our account - which stops us from using our operational tools (Denial of service).'

Explain possible mitigations for this threat, or why this is not possible.

For example, 'Mitigations: Ensure we have strict email settings, appropriate spam filters, and encourage our partners to improve their email security. Have a cybersecurity training programme that helps people identify and report phishing emails. Have a clear plan to handle reports of phishing promptly and effectively. Limit Google Workspace Admin access to few people, who should know the risks of adding new people directly to our organisation (or at least be aware this is something to check with others). Ensure Google Workspace security notifications are being sent to a monitored inbox.'.


Internal cybersecurity course (2023) session plans

Adam Jones • July 15, 2024