So, I am trying to figure out how to engage properly with the development/product team in my small startupish company. The security team is very small (At the moment, a singleton), so we can't really get in and review everything all the time, without support from the rest of the organization, but it is clear that we need some process and/or guidance to them. I'm thinking about a short 4-6 question checklist that we could use in product reviews, feature planning, and one suggestion was at Pull Requests as well, that would indicate whether it was worth engaging the security team. For example:
Has anyone ever done something similar, and had experiences they are willing to share, good or bad? Other ideas for questions would be great, too.
So my take is slightly different. I am concerned that you state " one suggestion was at Pull Requests as well, that would indicate whether it was worth engaging the security team", I like to tell my security folk is that the whole of security is only as strong as the weakest point.
Instead of asking them to be "honest" with Security, why not develop guidelines that all applications need to follow and advise the Business System Owners as well. The Development team may or may not know the answers to your questions and see it as an impediment to them completing on time.
I would add a set of guidelines to the design phase that the development team must adhere to while developing.
It would include things like:
1. All systems must provide an authentication scheme (define the parameters here, passwords, length of password, expiry, etc.)
2. Data must be classified according to a scheme (there are numerous available). This will assist you when you need to apply differing security technologies.
3. Define who should/should not have access to the systems.
4. Cover the use of encryption
5. As they sometimes also develop on alternate platforms...does it require AV
6. Determine if the application is in the Cloud. If so, have a list/questionnaire available for the Cloud provider to complete so that you understand how the data will be protected.
Check out https://www.owasp.org/index.php/Security_by_Design_Principles which is the OWASP Security by Design....I believe it will help you down the path.
This work will take a bit to put together but it will be re-usable across multiple systems.
Quite frankly questionnaires are useless. I like the reference given to the OWASP security design principles, but you need something simple. You need to build security into the SDLC, into the CI/CD pipeline to be friction-less and effective. Focus on integrating your security tooling into their dev and build environments and you will be successful, at least 90% of the time. The other 10% of the time is working with team on reviewing and assessing the business logic of the application because scanners are not smart enough to catch those kinds of defects.
I think the question is much like "Do I need a lawyer/doctor/fireman?". If your instinct causes you to ask the question, the answer is "yes".
The culture I have tried to promote is to stop by my desk and after a brief discussion, we will know if a broader meeting is needed.
The Application Security Verification Standard is a list of application security requirements or tests that can be used by architects, developers, testers, security professionals, and even consumers to define what a secure application is.
ASVS has two main goals:
to help organizations develop and maintain secure applications
to allow security service, security tools vendors, and consumers to align their requirements and offerings
The Application Security Verification Standard defines three security verification levels, with each level increasing in depth.
ASVS Level 1 is meant for all software.
ASVS Level 2 is for applications that contain sensitive data, which requires protection.
ASVS Level 3 is for the most critical applications - applications that perform high value transactions, contain sensitive medical data, or any application that requires the highest level of trust.
Each ASVS level contains a list of security requirements. Each of these requirements can also be mapped to security-specific features and capabilities that must be built into software by developers.
There are 19 security requirement verifications, each category will have sub requirements , so all together 200+ requirements.
I feel it's an excellent tool.
It's a product of OWASP.
Application Security Verification Standard 3.0.1
my 2 cents
We have code quality, SAST, DAST, peer review at Pull Request, automated API testing, etc., etc. We have all of that in the tool chain. The problem is that we are integrating new things at customer request, in an Agile environment of a small company, so things move very, very quickly. I am building a security program from nothing, and trying to find ways to promote the kind of culture we all want to see. A lot of the suggestions here are great, and some o f them we will get to, but right now, we need something to help people know when to throw up a flag, and get a second opinion.
I agree, one of the problems here is that we are a distributed company, my desk is in my house, as is everyone else's, so what I am looking for is something to stand in for dropping by my desk, since that isn't an option.