I have been on both sides of this, for me the engagement shouldn't be about saying no. It should be about working collaboratively with the delivery team to find the best way forward for a particular control. That involves the security professional articulating the why of the control, or even better as have done in the past demonstrating the impact of the lack of the control on the system being developed.
I have seen many cases where saying no just sidelines the engagements, and some other areas where a collaborative approach has achieved results.
Security people need to integrate with the delivery teams take credit when things work and take the wrap with the delivery teams when things fail. I have seen lots of emails in my time from security professionals asking how could they have been so stupid and very few asking what more could we have done to help.
Its all about collaboration and building trust.
I've seen both sides of this at an organization. A security professional needs to be approachable and helpful or people WILL circumvent them. Security also needs to enable the business, not hinder it or people WILL circumvent it. A proper risk assessment is always the first thing one should to as a security professional to figure out where to step in and put some pressure on something and where the attention isn't as needed. I've seen people waste countless energy and hours trying to fight a battle that really didn't need to be fought.
We scare people and only through the building of trust and company buy-in will this change. Then again, there will always be people that don't care and will break the rules.
Security has the reputation as the function that says no or may cause delays whilst they undertake threat assessment, risk assessment or due diligence. And whilst we may be capable of turning those around very quickly the outcome may not be want the person running the initiative wants to hear.
If it was your pet project or business idea, the thought of someone else pointing out the down side risks, evaluating them and producing a series of risk treatments may simply not be welcome. The treatments will almost have a cost and effort attached, which may break the business case for the initiative. Of course the get out of jail, is that if within risk appetite the project/initiative sponsor may chose to accept the risks as is.
But equally the sponsor may want plausible deniability that they were unaware of the InfoSec risks associated with their initiative and may remonstrate that it's all the fault of security for not being involved earlier. InfoSec are criticised for the sponsor failing to engage them early on, and then for carrying out their role when engaged. They attack as a means to cover a failure to think about risk or to acknowledge a down side, possibly because they're not secure in their decision making role and being held accountable for any negative consequences down the line.
It's the same with sensible business control, which get perceived as an obstacle. It could equally be legal compliance, written contracts, health and safety ....
Cases differ in nature, but if we are to generalize:
1. Time to market imperatives. Features that make business profitable will always supersede the need for security. I have seen that even in security product vendors behavior.
2. Convenience vs. security. Whoever thought that BYOD was a good idea from security point of view?
3. Culture. Rigidity of existing frameworks pigeonholing security professionals in a separate and distinct roles and limits the benefits they are capable of delivering. On the opposite side, in startups, the developers are the drivers of innovation, but are clueless about security. Yet most of the security job description beginning to list programming as a necessary prerequisite. With very few exceptions, people that trying to make new things are not the same who are seeing the big picture from security point of view.
4. Resources. Bringing outsiders and expecting them to really understand your business and its imperatives as well as being able to communicate effectively with all stakeholders and convince them of either benefits of security initiatives or the consequences of the lack of those not in generic terms is never easy. And even when it is possible, exceedingly expensive. Not as expensive as the alternative, but people are very good at thinking in retrospects.
Simple answer? Because I cannot afford the time to be in meetings all day and get anything else done all day. Being a operator of a one person security shop I don't always have the luxury of being in every meeting and discussion I should be in.
Speaking of which... its time for another meeting.
Reasons People Avoid Security Professionals:
- It's Normal for most people to ostrich on security until something bad happens.
- Colleagues are focused on other wiz bang features.
- Security is still largely viewed as a set of features, the development of which is an opportunity cost against the wiz bang features.
- There is a belief that adding security makes the product harder to use.
- Say yes. Position security aka risk management as a business/product enabler.
- Cultivate an integrated Secure Development Lifecycle (SDL) mind set in your institution
- Use automation tools/ML/AI in the build chain - reduce manual work load wherever possible
- Show the value - A legitimate SDL will show returns in engineering process, customer value and averted events almost immediately. Capture that data and make sure exec management understands the benefits.
- Lastly, take advantage when an event occurs to raise awareness. Respond quickly and show how the system can evolve to avoid similar events.
John MacInnis, CISSP
"Security is a Journey, Not a Destination"
I'd suggest that in addition to "events averted" the documented impact on industry peers or competition that were not able to avoid it should be included.
Absolutely, I am testing my own beliefs and abilities to be exact. I am an architect myself. We see security as part of the qualities of the entire solution design phases through to confirmation from the client. It is a Non Functional Requirement (NFR) if you like which can be measured. Good to find another like minded person.
Probably off topic for this thread, but how are the security NFR's measured? I've come across that term which seems to justify limitations on security - if specific technologies are not defined with the NFR, then they can be ignored. Furthermore a security NFR is separate to the whole ecosystem. I'm hoping to get a handle on this to help me change some mindsets...
You could probably attribute that to the general mindset hovering on ‘Leave well enough alone.’
If a system is working fine, an entity won't be too keen on improving its security --- unless the costs of this are justified by the benefits, and the entity is aware of and unwilling to accept the risks of less security.
Organizations would see the implementation of IT Security as an immediate cost. Even if its long-term benefits can be proved, not everyone wants to wait that long...
Individuals usually opt for high convenience at a low cost, and implementing IT Security may affect both of these, often not to the liking of consumers...
Or as often the case, their risk appetite is very large, and adequate for their business or perceived needs.
Well they think they are covered, or when was the backup actually restored and re-verified etc.
Therefore as you why do I need this, everything is working well, until that dreaded day, when all hell breaks loose, and everyone runs around like headless chickens, whilst they attempt to resolve the sense of panic, that often breaks out during these situations.