What is your code’s security posture? Six steps to prepare.
What is security posture?
We’ve all heard the proverb:
A chain is only as strong as its weakest link.
And while this is true in the literal sense, the metaphor also fits well when applied to a code base or project repository.
Why spend three solid days ensuring SQL queries are all injection safe if your API authorization layer doesn’t protect content properly via Role Base Access Controls (RBAC) and two-factor protected access tokens?
We define security posture as the combined strength and efficacy of a company’s cybersecurity policies, controls, and risk mitigation, but we can also apply this to an engineering team.
Consider these questions:
- How secure is our distributed repository? Who can push to the master branch?
- Is every user required to have MFA in order to use our repository?
- How comprehensive is our security code review?
- Can we accurately measure Open Source vulnerabilities?
- Do we have a process in place to monitor Open Source vulnerabilities?
- Who determines compliance for system tools and operating systems?
- How effective is our vulnerability management?
- How do we test our application security?
Understanding application security
While providing a thorough guide to hardening a team’s security posture would be one great gift I could give to the world, its not reasonable for me to tell you how and what to do. Instead, I can provide some steps to quickly define a posture and take action and next steps.
Step 1 — Determine your vulnerabilities
What would be the major loss or result if your application was compromised?
Data Exfiltration
- Financial Data?
- Intellectual Property?
Identity Theft
- Financial Data?
- Private Records?
Denial Of Service
- Critical Business Functions?
Pure Pwnage
- Monetary Theft?
- Zombie bot net
Step 2 — Determine your targets
What are your targets? What kinds of applications do you manage and are they available on the internet?
- API system
- Auth system
- User system
- Background processor
- Is your public facing API a target (most of the time yes!)?
- Are your developers targets (usually!)?
Step 3 — Audit your targets
If you have access to an internal Red Team, have them attack your app (in a controlled environment please!). How secure are your targets? Do a preliminary audit on all the targets.
- Do you have any non-prod environments? Are they secure and off the internet?
- Are your cloud projects isolated, or is there dev code running nearby prod code?
- Are there timely scans of open source packages and containers on every build or deploy?
Step 4 — Plan
Now that you have your targets identified in a basic list, flesh them out! Figure out what kinds of controls are in place to prevent accidental or unauthorized security events. Write them down — because then you will fix them!
Determine ways to measure security that fit your team code and architecture:
- Total open source vulnerabilities
- Total code level security lint vulnerabilities
- Total architectural vulnerabilities
- Total operating systems vulnerabilities
Step 5 — Monitor
While we all can’t drop in a fancy expensive SIEM system to be a watch dog on all of our systems, basic application code logging, error tracking, and metrics collection are nearly free or cheap depending on your cloud provider, and can be easily enhanced via open source libraries and offerings.
- StatsD / Prometheus / Stackdriver
- Sentry / Rollbar / New Relic
- Papertrail / Logstash / Loggly
- Slack and Email
Step 6 — Defend and Improve
As you discover vulnerabilities and issues, you and your team will fix them, but should also prevent them again with new controls or processes.
- Keep scanning — runtime scanning and static analysis
- Code review and security review
- Continue Red Team attacks
- Stress test your application
- Annual training on CyberSecurity
- Phishing training
- Talk to your team — sometimes internal cybersecurity incidents can be avoided by simply being friendly with coworkers
Conclusion
Obviously, navigating and planning security is a time-consuming process with many complexities, arguments, and smart minds colliding.
Moving towards a shift-left mentality for security should be the goal of every engineering team.
