Short list of questions to engage the security team or not

[mgorman]

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:

1. Does this feature involve Personally Identifiable Information?
2. Does this feature involve customer sensitive information?
3. Does this feature involve a new vendor?
4. Does this feature involve company sensitive information?

???

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.

[dcontesti]

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.

7. ETC.

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.

Regards

Diana

My

[JPC]

Hi mgorman,
I know the pain of being in a small security team and being unable to do everything all the time.
Some points that helped me engage with our Development team was to (as per dcontesti's reply) develop guidance for the team to work from as a way to prevent drag on their development times (which becomes all the more important in Agile Development methodologies).
With specifics to the 'if data = PII or Business sensitive', you could expand this into a 'so what' matrix i.e. Data classified as Confidential (PII/Business sensitive) then enforce encryption in transit/rest, strict authentication, auditing, IP restrictions etc. If Data classification = public then encryption in transit preferrable (at rest not required), authentication may be anonymous, IP restrictions not required etc.
It may also help your ITSec team to empower a Dev to be a security champion. This gives the Dev team a focal point in the team for secure code questions, helps to ensure the security guidelines/principles are implemented and also a single point to escalate queries/problems to the ITsec team.
Security champions require a culture change from both the Dev and IT teams, which can be difficult, but the results are ITsec is only informed on what they need to be and Dev teams don't have as much drag on their builds.

[rslade]

> JPC (Newcomer I) posted a new reply in Tech Talk on 05-04-2019 01:59 AM in the

> Hi mgorman, I know the pain of being in a small security team and being unable
> to do everything all the time.

OK, I've got a question for the techies amongst us: what's wrong with the sign in
process?

The sign in process is seriously borked, at least in some regard. I haven't been able
to sign on in over a year, on multiple platforms, under multiple broswers. (I know
that other people *have* been able to, but I doubt I am the only one who can't, so
I suspect that a number of people who actually *want* to be on the "community"
[although I can't imagine why], can't.)

So, how am I posting here? Well, using the "reply via email" function I can reply
to posts (well, some: since I started using it it seems, consistently, to fail about
30% of the time), so that's why my postings are showing up in odd and
inappropriate places. (Using "reply via email" I have no control over that.) I
can't create any new posts, of course, so any new industry news I get I'll either
have to keep to myself, or post as a reply in odd and inappropriate places.

(For "reply via email" you have to "subscribe," so you get notifications by email,
and then you can use the links in those emails, like:
> You can respond to the reply at the following URL:
> mailto:isc2.prod|10b20d16|175364f9-e175-4d4e-9cad-
9e854ddadd88@reply01.lithium.c
>
om?subject=Re:%20Short%20list%20of%20questions%20to%20engage%20the%2
0security%20
> team%20or%20not )

Just for debugging purposes (in case this ever gets reported to the actual
developers), there is *some* communication going on in the sign in process,
because, if I make a mistake typing my password I do get an error message.
However, if I type the correct username/registered email address and password,
absolutely nothing happens: no message, no response--and no access to the
"community."


====================== (quote inserted randomly by Pegasus Mailer)
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org
Never mistake motion for action. - Ernest Hemingway
victoria.tc.ca/techrev/rms.htm http://twitter.com/rslade
http://blogs.securiteam.com/index.php/archives/author/p1/
https://is.gd/RotlWB

[AppDefects]

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.

[denbesten]

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.  

[iluom]

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

[mgorman]

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.

[mgorman]

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.