A List of Secure Defaults
I think secure defaults / building a “paved road” for developers is one of the best ways to scale security. So naturally, I like this post by Abhay Bhargav. He also lists a number of useful secure by default libraries at the bottom, covering cryptography, client-side output encoding, input validation, and more.
Using SAFe® to align cyber security and executive goals in an agile setting
Nicely detailed article by F-Secure on threat modeling effectively in agile dev environments. It discusses threat modeling at two different granularities: epic planning (higher level) and feature planning (more tactical, specific tasks to be done).
Though it may be tempting to create a security epic under which to add all security work, this should be avoided. Doing so would lead to work not being suitably prioritized, with security needs not explicitly linked to business value. It’s possible that security requirements buried under their own security epic never get seen again by anyone in the business.
Instead of treating security and privacy aspects as non-functional requirements, the goal is to make them features and enablers in their own right. This forces product management to make explicit decisions when allocating developer time for functionality or security. Security over spending is kept in check as a result, whilst direct evidence of security work is proven through its ticketing.
Performing threat modelling within feature refinement. The team has either enough time for threat modelling here, or the features that require threat modelling are simple enough.
When threat modelling seems to take a lot of time, it can be pushed onto the Program Increment with all the development work. The threat modelling results may cause changes to the increment content, or the results can be just pushed on the backlog for later implementation.
Security and privacy work need to be visible on backlogs. This visibility will make time allocation and relative priorities explicit and at the same time produce evidence of security work performed. It will also give organization’s security and privacy functions a way to follow up on the security activities without extra reporting.
Don’t use non-functional requirements with security. Each security requirement needs to boil down into either a hard, functional requirement or an actual enabler.
Our AWS bill is ~ 2% of revenue. Here’s how we did it
Sankalp Jonna describes how their bootstrapped start-up kept costs low by choosing the right cloud products. Specifically: Lightsail instances instead of EC2, RDS, and ElastiCache (Redis), using the build-in Shopify CDN instead of CloudFront, self-hosted NGINX instead of ELB.
How to use G Suite as an external identity provider for AWS SSO
“You can grant access by assigning G Suite users to accounts governed by AWS Organizations. The user’s effective permissions in an account are determined by permission sets defined in AWS SSO.”
“Simple AWS Lambda powered Slack bot that reports your AWS Costs for the current month to a channel.”
Helps you find over-privileged IAM users and roles by comparing CloudTrail logs with current IAM policies, by Scott Piper.
Validating Kubernetes YAML for best practice and policies
@Learnk8s article that compares six static analysis tools to validate and score Kubernetes YAML files for best practices and compliance: kubeval, kube-score, config-lint, copper, conftest and polaris.
A collection of diagrams explaining Kubernetes (e.g. Deployment -> Pod -> Container, services, nodes, and pods, etc.). Written in PlantUML, so they’re easy to edit.
A tool to passively discover active hosts on a network by monitoring ARP traffic. Extracts basic data about each active host, such as IP address, MAC address and manufacturer.
SierraTwo: A simple reverse shell over Slack
Abusing GitLab Runners
Nick Frichette describes how GitLab runners work, and how if you gain access to a GitLab runner registration token, you may be able to access the source code of a project to which you do not have access, pilfer environment variables potentially gaining sensitive secrets, and more.
Politics / Privacy
Twitter thread by Moxie on Signal PINs
Privacy Links by productsecuritygroup.com
Forums/Groups/News sites, law firm blogs, tools and methodologies, articles (“privacy by design”), and more.
Why I Believe Trump is Compromised by Russia
Too often I feel people have been getting caught up trying to concretely prove collusion. This post by Daniel Miessler asks, in my opinion, a much better question: “Are Trump’s actions helping Putin’s long-term plan to diminish the United States’ position in the world?” From fighting with our allies, to bungling COVID-19, to pulling out of the WHO– again and again, it’s making America less respected and influential in global politics.
Evidence-based Software Engineering
An ambitious (free) book that examines a massive number of studies about what factors and environments lead to effective software engineering.
Interesting Stratechery (Ben Thompson) article on Slack vs Microsoft Teams. Teams has likely surpassed Slack in Daily Active Users (DAU) due to a combination of factors: it’s free (if you have a Microsoft 365 subscription), Microsoft has a massive team and partner network in which it shares subscription revenue for Azure and Office 365, and an ecosystem that all plays nicely together (One Drive, Planner, …).
By virtue of doing everything, even if mediocrely, Microsoft is providing a whole that is greater than the sum of its parts, particularly for the non-tech workers that are in fact most of the market.
How does Slack double down on its advantages and stay differentiated? Shared channels, that enable easy communication between different companies.
"Slack Connect is about more than chat: not only can you have multiple companies in one channel, you can also manage the flow of data between different organizations; to put it another way, while Microsoft is busy building an operating system in the cloud, Slack has decided to build the enterprise social network."
Snippets from a letter by Richard Feynman to one of his former students.
Unfortunately your letter made me unhappy for you seem to be truly sad. It seems that the influence of your teacher has been to give you a false idea of what are worthwhile problems. The worthwhile problems are the ones you can really solve or help solve, the ones you can really contribute something to. A problem is grand in science if it lies before us unsolved and we see some way for us to make some headway into it. I would advise you to take even simpler, or as you say, humbler, problems until you find some you can really solve easily, no matter how trivial. You will get the pleasure of success, and of helping your fellow man, even if it is only to answer a question in the mind of a colleague less able than you. You must not take away from yourself these pleasures because you have some erroneous idea of what is worthwhile.
You met me at the peak of my career when I seemed to you to be concerned with problems close to the gods. But at the same time I had another Ph.D. Student (Albert Hibbs) whose thesis was on how it is that the winds build up waves blowing over water in the sea. I accepted him as a student because he came to me with the problem he wanted to solve. With you I made a mistake, I gave you the problem instead of letting you find your own; and left you with a wrong idea of what is interesting or pleasant or important to work on (namely those problems you see you may do something about).
I have worked on innumerable problems that you would call humble, but which I enjoyed and felt very good about because I sometimes could partially succeed.
No problem is too small or too trivial if we can really do something about it.
You say you are a nameless man. You are not to your wife and to your child. You will not long remain so to your immediate colleagues if you can answer their simple questions when they come into your office. You are not nameless to me. Do not remain nameless to yourself – it is too sad a way to be. Know your place in the world and evaluate yourself fairly, not in terms of your naïve ideals of your own youth, nor in terms of what you erroneously imagine your teacher’s ideals are.
📚 Reducing Our Attack Surface with AppSec Platform
Michael Whiteman describes a neat automation platform they’ve built at WW (formerly Weight Watchers), that can continuously discover, monitor, and assess the security posture of web assets. Asset inventory FTW! 🤘
Here are some things I love about this approach:
- You're getting a continuous, programmatic update-to-date view of your attack surface, and can easily focus on the new and most risky apps.
- New tools can easily be plugged in, so the AppSec Platform gets incrementally, progressively more useful over time.
- Contextual info that the security team needs to assess a situation is grabbed automatically.
- It integrates with the security team's existing tools and workflows (e.g. Slack).
1. Asset Discovery and Reconnaissance
Scanning tools (Amass, Subfinder) are deployed as Kubernetes jobs, running between every five minutes to one hour, and results feed into the AppSec Platform API.
New assets are particularly interesting, so the Product Security team is notified via a Slack message when a DNS record is discovered for the first time.
New assets are automatically screenshotted with Aquatone, their tech stack is fingerprinted with Wappalyzer, and port scanned with nmap.
2. Continuous Security Monitoring
Apps are then scanned for security issues that are easy to find and fix and that can be identified quickly at scale, including CORS or TLS miconfigurations, subdomain takeovers, exposed secrets, and content discovery / server misconfigurations.
The Product Security team receives a Slack alert for each identified issue, who can then process the issue directly from Slack.
The issue database is automatically updated when the Slack message has been triaged or when the scanning tools no longer detect an issue, which marks them as fixed.
3. Platform Dashboard
The Platform Dashboard provides CRUD operations and searching capabilities, so that team members can analyze and monitor data in real time, like:
- What web apps are using a given third-party component or library?
- Do any apps have potentially dangerous ports or services exposed? (e.g. anonymous FTP, ElastiCache, Redis, etc.)
- Which apps are written in “non-standard” programming languages (e.g. PHP)?
We frequently consult the dashboard to identify potentially higher-risk applications and drive attack surface reduction with the appropriate teams.
✉️ Wrapping Up
Have questions, comments, or feedback? Just reply directly, I'd love to hear from you.
If you find this newsletter useful and know other people who would too, I'd really appreciate if you'd forward it to them🙏
Thanks for reading!