Crafting your AppSec Learning Methodology

Information Security is a broad field with many specialties such as Infrastructure Security, Cloud Security, Container Security. DevOps automation and Application Security (Source Code / Design level) etc. In real life context, an Application Security may need to focus on a few specialties since modern applications are using Cloud PaaS / IaaS and Containers.

Since there are so many specialties to learn, you may get overwhelmed by the knowledge and how to apply what you learn on the actual context. I read an interesting Div0 post on a cybersecurity career discussion panel on this topic:

Many aspiring cybersecurity practitioners say they are passionate about cybersecurity. But they have no work to show/prove their passion. Don't just say you are passionate. Do it, show it!

There's no shortage of aspiring cybersecurity practitioners who want to learn. However, there's a lack of drive on how they can contribute to the organization. Continuous learning in a fast-moving industry like cybersecurity is important. However, you should also focus on how you can apply your skills (emphasis mine).

Cybersecurity is not just about technical skills. In fact, picking up technical skills is the easy bit. Shaping your attitude and mindset in how you deliver the promise your clients entrusted in you plays a much bigger role.

An essential characteristic to have in the industry is Grit — the passion and sustained persistence towards long-term achievement.

In a wide discipline like cybersecurity, it is important to collaborate and bounce ideas with fellow practitioners — that's how you push the boundary.

The mad rush to get all the fancy certifications is not healthy. There's no point being certified but you still can't get a complete grasp on security controls or even the fundamentals. Focus on building up your skillset, not the alphabets behind your name.

Often Application Security new joiners have to learn development skills on their own projects if they are not joining from development background. They may be pentesters, sysadmin, DevOps engineers or career changers coming from another field. Each of them have their own unique perspectives.

You need to understand development but...

If you see in many Application Security job descriptions, many companies require development background. This requirement ensures that you can empathize with the development team that you will be working closely with.

Be careful not to become too developer-like because you will lose independent assessment since you are too close to the development team. For example, some developer tells you that this SQL injection is not a risk since the string values come from hardcoded config file. If you get too close to dev team, you might accept the risk without pointing out additional caution.

However, from another independent perspective, this means that SQL injection can happen if a rogue developer / QA / devops change the config file to a SQLi payload. The long-term solution is actually to use parameterized query and prepared statement even though the values are hardcoded. However if you get too close to dev team, you will start to feel their pain and deadlines if the feature is not released on time. So you might not even suggest the team to pick a more secure approach. Or you might ask the team to add this suggestion to backlog. It remains to be seen whether the safer approach will be adopted since there is always another new feature to complete.

Security Champions might also struggle to give independent assessment especially since they are part of the dev team. Moreover, many of them are developers or QA and have deadline and user stories to complete as well. Therefore Security Champions cannot do it alone and need pairing with the internal Security SME to give a balanced assessment.

On the other hand, you are too far from the development team, you will start suggesting crazy security activities from some PDFs or slides that will never gain any traction with the development team. Many good ideas sound great in powerpoint slides but difficult to gain traction in practice because real world has more decision-making factors in which security is just one of them. You need to at least understand some of these major factors such as business risk appetite, ROI, regulatory requirements etc.

Not enough to learn Development

To understand Application Security in depth, the newbies have to pick up coding and software development concepts such as MVC etc. on their side projects or on the job. It will take time and requires a lot of experimentation, readings, note-taking and questioning.

You shouldn't just learn coding like watching a Udemy course on Web Development or Mobile Development. After all, your job also consist of the security aspects of delivery. Most of the development courses will not mention Application security topics. This means that you need to create your own contexts to apply every topics that you have watched on Application Security.

An example of I apply newly learned security knowledge to coding

Recently, I attended an online webinar on building secure React applications. This is an informative talk with hands-on examples that I recommend people to watch.

My first thought is to find the React code that I wrote on my own.

import React from 'react';

const Option = (props) => {
    return (
        <div>
            <li>{props.name}</li>
            <button
                onClick={(e) => {
                    props.handleDeleteOption(props.name);
                }}
            >
                Remove
            </button>
        </div>
    );
};

export default Option;

Previously, my understanding was that ReactJS is secure by default library and XSS is difficult to achieve unless developer use dangerouslySetInnerHTML. But from the video, I updated my understanding of ReactJS and recognized more XSS attack surface.

Then I tried to modify my React component code to create the XSS vulnerability. Imagine the developer thinks that getting the name from props is safe to use in href.

import React from 'react';

const Option = (props) => {
    return (
        <div>
            <li>{props.name}</li>
            <a href={props.name}>Click for more info</a>
            <button
                onClick={(e) => {
                    props.handleDeleteOption(props.name);
                }}
            >
                Remove
            </button>
        </div>
    );
};

export default Option;

But if the attacker include JavaScript url, then there is a stored XSS issue.

From now, when I look at ReactJS code, I will also include such checks in my code review methodology. Or when I am looking at ReactJS app, I will be more awareness of more things to look out for such as href and src tags etc.