Presentation Material
Abstract
How often have you heard that ‘Early stage startups don’t care much about Security because if there is no product, there is nothing to secure?’ Although there is merit in the argument that startups need to build product so as to sustain and grow, it often puts the person in charge of securing them in a tricky position. For most startups, this person is the first Security Engineer who can be somewhere between the 10th to 300th employee. By the time the first Security Engineer is on-boarded the attack surface has usually become quite large and he or she faces an uphill battle to go about securing the organization. In such cases, the Security Engineer needs to perform as a ‘one-man army’ keeping the attackers at bay. In this talk, i will present a playbook on how to perform as one.
In this presentation, i will talk about the Startup Security methodology which has served me very well in starting, building and growing Security teams at various startups. The focus and goals include :-
- DevSecOps – You are in-charge of everything
- Automation is your friend – Alerts significantly better than watching or monitoring a tool
- Secure, Document, Repeat!
- Developer empathy – It is new for them
- Build vs Buy – Maximizing ROI in terms of money and time
- Security Education and Awareness
- IPad signing technique – Risk consumption and buy-in
- Alignment with upper management before you accept the job – Budget, Headcount, Goals, Timeline etc.
I will also recount war stories from experiences including mine from when I was the first AppSec Engineer at Duo Security (acquired by Cisco), was founding engineer at Elevate Security and started the Security team at MileIQ (acquired by Microsoft) and those of my colleagues who have been in similar shoes.
AI Generated Summarymay contain errors
Here is a summary of the content:
Value of Security Engineers: The speaker emphasizes the growing importance of security engineers in companies, Iike compliance certifications (ISO, GDPR). Without security engineers, companies may struggle to sustain themselves.
Being an Enabler, Not a Blocker: To avoid being hated by colleagues, team members, security engineers should adopt an “enabler” philosophy. Instead of constantly saying no, they can help teams build robust secure development life cycles (SDLs) and ship more secure code.
Justifying Increased Security Team Size: To get justification for increasing the security team size, show the value of your work by highlighting risk reduction and impact on the organization. Then, present a list of additional tasks that need to be done, demonstrating the need for more resources.
Measuring Training Effectiveness: The speaker recommends metrics such as escape rate of bugs (identified at different SDL phases) and time to fix those bugs to measure the effectiveness of training application security designed for developers.
Additional Recommendations:
- Running simulations can provide valuable data on training effectiveness.
- Phishing campaigns, security awareness tests, and bug bash days can help identify vulnerabilities and improve security.