DISQUS

Jon · 9 months ago

I look at it like this. If you are a member of one of the companies line functions: design, production, sales, transportation, wholesale and retail, then you are a business enabler. If you are a staff function: legal, secretarial, custodial, PR, training, etc. then you are an expense. I consider security to be a staff function, but I may be wrong.

cooperati · 9 months ago

re: Security as a “Business Enabler”;

i ask what about "risk" as an enabler? enabling is like opening doors, to enable, to make able, to create an opportunity to present your ability.

so, by opening that door, we enable, and we also take the risk also associated with it. to enable is to stick your head in a guillotine, to one extent or another. enabling is intrinsically risky. the two can go hand in hand.

security is, in opposition to risk, disabling. it defines limits of risk, specifically by disabling discriminately.

security does not open doors. it does not present opportunity. it frames ability with rules and protocols, trimming the field with limits and controls. thoughts?

i lack precision (for precise terms). but, philosophically speaking, security is not enabling.

so, you might ask, "What if you can't do a project unless security is in place?"

the project is the ability. security is the limits and protocols. boundaries, whatever you want to call it.

just saying "the project cannot proceed without security" is the first act of security disabling the action, coinciding with and reinforcing the definition.

thoughts?

joej · 9 months ago

If you don't perform basic "good health" engineering and development, then *sure* ... security is not an enabler. Security is one of those dumb, slow-you-down, "cross your Ts and dot your Is" anal retentiveness.

However ... if you worry about produce reliable, error free systems or software, then you include good practice, techniques, double-checks, etc as part of the dev/eng processes (called; "security") and you bring in some testing/external checks to ensure you didn't make obvious mistakes.

Looking at the Top-25 CWE list, repeated, low-level, obvious-to-spot and remediate (and abuse) flaws in systems and software ... I'm thinking this:

... The perception that security is a burden, comes bad practitioners: either security or the eng/dev folks on their team. Security is (again) not the problem, its a people problem.

Daniel Miessler · 9 months ago

I think this is in line with what I'm saying; it's a matter of quality ultimately, and security is a component of that, yeah?

joej · 9 months ago

Definitely. I'm with you on this.

I really do believe that, if infosec/security folks are doing a good job, then there is a gained efficiency (not just robustness, resilience, etc.)

One recent example:
Moving to field a DoD system to the field, we coordinated with the defense contractor to leverage Fortify SCA -- a manual code review would have been VERY costly.

This was focused *only* on the information assurance/security necessity (requirement, policy, etc.) - but they ended up loving its strength, got over their embarrassment at the kind of flaws that were in the code base and, in the end, moved to integrate this as part of their normal development & build practices.

End result: we saved (literally) millions of dollars (or) pursuing a waiver and fielding known-flawed code -- and we both got what we really can value:
- my organization gets improved quality/security and can oversee/audit a practice
- they get something that moves them forward more efficiently and keep us out of their shorts :-)

Nice win -- money and a practical, sustainable practice that dramatically affects what we produce.

==> I'd love to hear other, real-world examples of security + engineer/dev collaboration to produce successes.