In the name of Security Engineering, Please stop !!

OP-ED !!

After working for many organizations as a full-time & CW security engineer, interviewed as well as interviewing for the position more than 100 times, I am writing this blog to help my fellow security engineers identify red flags during interviews as well as the existing team. So that they don't commit mistakes that I have made.

First lets us accept that there is a huge shortage of quality security engineer, I see many security engineering position open for years. EX.- Security engineer II/III at UBER. You might have also got a mail 😛 . In India there are 100 unicorns, let's say everyone has a security team of 8 members. That's 800 security engineers in unicorns alone.

What are the responsibilities of a security engineer and what are the minimum tech skills required are well documented by the GitLab security team -https://handbook.gitlab.com/job-families/security/security-engineer/.

Points to note if you are joining a new team-

• Many teams are created just to fulfill compliance requirements. Don't join if you are ambitious or interested in learning something. Always ask in interviews what are the goals of this team. Else you will end in a vicious cycle with scanner reports.
• Always check for the JD thoroughly, If there is no mention of SAML, OAuth, JWT or neither they ask anything about these in the interview be careful. Authentication and authorization are most important for any organization.
• Always ask questions during the interview, "What your daily schedule looks like". I always ask in the final round " How do you make sure your team is updated on new attacks or methodologies like request smuggling or other attacks".
• Another very important point is low interview standards. They didn't ask you anything out of OWASP Top 10. If you find interviews are very easy compared to other organizations, don't satisfy your ego. If you join a team that trusts scanner results or a sub-par team, you will be stuck there as a trainer.
• After all the interviews always check for other team members' linkedin/Twitter profiles before joining. Reach out to them, and ask for honest opinions if you are planning to join them.
•  Always ask what I will do if I join your organization. It might be possible you are not interested in working on something where they see you will fit in.
• I always leave interviews, if someone asks owasp 10 serially. For me, it means they want someone who can fulfill the checklist. Threats are dynamic and usually based on user stories /features.

• Not updated with the latest attacks and methodologies. I remember one of my managers told us if you are not updating yourself you are not even pentesting the application completely because you are omitting the new scenarios. He scheduled a weekly call only to discuss what's new. The best manager I have worked for by far.
• Running behind tools. There are thousands of tools currently for different solutions. Instead of solving engineering problems, security engineers are just integrating tools without thinking about scalable solutions. That ultimately results in noise without solving the real problem. Even a school kid can search for tools.
• No incident response planning. Many teams live in illusion believing that there will be no breach. Be prepared for the worst. I remember my previous manager made sure our team had "dry runs for black swan events" every quarter OKRS. Shout out to him.
• Not having Zero trust arch. Incidents can happen from anywhere, a zero-day like log4 or from a third-party supply chain like Solar Wind or any. Zero trust arch helps you to containment without blowing off your infra with a single shot.
• Not having enough planning. OKRs/ projects should be aligned with organization goals as well as changing cyber threats across the world. Also, many teams don't have any timeline or ETA for tasks due to weak leadership. These teams end up in a cycle where till one task is complete, it's already 6 months, and a new type of threat vector getting exploited in the wild and you have no guard.
• Not understanding existing dev culture. If you want to implement security into DevOps, cool. But many critical issues can be solved by understanding, and communicating with developers How they code, where they download their dependencies, and What they use for data visualization. I know many teams use superset for data visualization - https://thehackernews.com/2023/04/apache-superset-vulnerability-insecure.html. If you don't know what your organization's assets are, how can you even secure them?
• Not getting involved from the development phase. Only pentesting just before release is not enough. With already insecurely designed products, generally security engineers are invited late to the party. After pentesting, Dev teams will have a thin window to fix the issue. In this case, usually dev team takes exception or lowers the severity and release. Promote threat modeling, and get involved before a single-line code is written.
• Relying solely on a checklist approach, such as OWASP, has its limitations. While it provides a valuable foundation, it may not encompass all potential attack vectors, leaving security teams vulnerable to unaddressed threats. For instance, when evaluating an OAuth integration, blindly following a checklist may lead to testing irrelevant functionalities like file upload/RCE, which could be a waste of critical time. Unfortunately, in some cases, checklists are used by security engineers to fool the management, like asking 2-3 weeks timeline because they need thousands of test cases to be verified.
• Not having secure defaults. Secure defaults prevent a lot of load from the security team. Some easy examples- auto deployment CSP, x-frame -options, CORS policy, and Cloud encryption policies throughout.