66

CTO Security Checklist

 5 years ago
source link: https://www.tuicool.com/articles/JvEf2u7
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Your code

  • Add security bugs to your incident tracking tool

    seed

    Every developer should contribute to maintaining a list of security issues that need to be fixed in the future. Making them available to the rest of the team will increase security awareness in your company.

    Treat security bugs like any other type of bug – determine their priority based on whether or not they are exploitable and the damage that could be done. Additionally, hold post-mortems for serious security bugs with the team to ensure that everyone gets visibility and learns from them.

  • If your security practices impact your development velocity, they will be looked at as more of a burden than a valuable step. The best practices today are to take lessons from DevOps and find ways to bring security closer to developers. Leverage tools that can automate security checks and monitoring. Implementing automated SAST/DAST tools, vulnerability dependency scanning, and others will help you catch the obvious flaws before they get into production. Just beware that you’ll have to sift through false positives and that these tools have limited scope.

    Read more:

  • Security should always be kept in mind while coding. Pull request reviews should be performed with security in mind as well. Depending on where the code is, the checks should be different. Dealing with user entry is one thing, dealing with business structures is another – the concerns are related to the context.

    In addition to common sense, keep in mind typical security flaws. For example, many code snippets from places like StackOverflow have not been written with security in mind. If your team pulls code snippets from the Internet, make sure they double check them for security before deploying them.

    Security competency is also a good topic to ask about when interviewing a candidate.

    Read more:

  • Never commit secrets in your code. They should be handled and stored separately in order to prevent them from accidentally being shared or exposed. This keeps a clear layer of separation between your environments (typically development, staging, and production).

    Read more:

  • Always rely on existing mechanisms, libraries, and tools. Cryptography is an expertise. Building your own implementations, or using flags and options you don’t fully understand, will expose you to major risks. Libraries such as na.cl ( https://nacl.cr.yp.to/ ) expose only a few options and restrict you to the good choices.

  • Onboard your software engineers with a security training

    series B+

    Secure applications start with secure developers. Your software engineers need to be aware of security best practices in order to write secure code and to perform security-minded code reviews. Since security is usually not something hiring managers consider during recruitment, an initial training at onboarding will help your devs reach a minimum level of security.

    Also, consider checking for security competency during the hiring process. This will help you better shape your training.

    Some good security training options:

  • Once in a while, the entire technical team should sit together and spend time targeting all parts of the application, looking for vulnerabilities. This is a great time to test for account isolation, token unicity, unauthenticated paths, etc… You will heavily rely on your browser’s web console, curl, and 3rd party tools such as Zap ( https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project ).

    The benefit of doing these test sessions yourselves is that your team has the best understanding of your application, and likely where the weak points are. Showing that they can be exploited (or not) is valuable feedback for the team. These sessions complement external pentests quite well.

    Read more:

  • Pre-production analysis tools like static code analysis (SAST) can help identify some of your low-hanging security fruits. They also improve the overall security awareness of your team when the checks are automatically integrated into the code review process. But keep in mind that these tools generate a lot of false positives that can quickly overwhelm you with meaningless alerts. The best practice is to make them part of your process, but not too rely too heavily on them.

    Tools:

  • The secure development lifecycle is a process that helps tackle security issues at the beginning of a project. While rarely used as is, it provides good insights at all stages of the project, from the specification to the release. It will allow you to enforce good practices at every stage of the project life.

    Read more:

Your application

  • Automate security once your app is in production

    seed

    Several tools offer ways to automate custom security protection in production. Wherever possible, leverage your business information and logic to automate monitoring and protection of security situations systemic to your particular business. The more you can automate, the easier you’ll be able to scale your security.

    Read more:

  • If you’re using FaaS in your company, you should ensure that it’s not a weak point for security.

    Make sure:

    • Your code is centralized - either in a FaaS-specific repository or within the applications that the function depends upon
    • Deployment is centralized in the CI. With FaaS abstracting things for you, it can be easy to forget about the different functions!
    • Privileges used by the function are minimalist (and distinct from the privileges used to deploy it)

    On top of that, FaaS should follow all the security criteria that you apply to your applications - from specifications, to development, to operating in production.

    Read more:

  • Hire an external penetration testing team

    series B+

    Pentesters take an external and naive point of view of your infrastructure and products. They will take nothing for granted and will check even the most basic assumptions, as well as all of your infrastructure. The experience can help focus your security efforts and mindset.

    Read more:

  • Applications are built using dozens of third party libraries. A single flaw in any of these libraries may put your entire application at risk. According to OWASP, one of the most common application security risks is using dependencies with known vulnerabilities. Some tools allow you to check your dependencies for vulnerabilities and ensure that they are up-to-date:

    Read more:

  • In the case that an attacker does successfully attack your application, having it running as a user with restricted privileges will make it harder for the attacker to take over the host and/or to bounce to other services. Privileged users are root on Unix systems, and Administrator or System on Windows systems.

  • Use a real-time protection service, like a RASP

    seed

    These days, WAFs are pretty outdated. It’s better to use services that sit closer to your application. These tools protect web applications from attacks at runtime. An Application Security Management (ASM) tool can do for security in your application what APM tools do for performance. They can monitor and protect against all major vulnerabilities (SQL injections, XSS attacks, account takeovers, code injections, etc…) without false positives.

    Read more:


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK