Performing a security review? Ready, set…pushback!

In an ideal world, security would be transparent, pervasive, adaptive and always-on; to consistently enforce a set of controls that mitigate risks down to an acceptable level.

In the world that most of us spend most of our time in, the security program aims to integrate security awareness into the DNA of the organization and protect the competitive edge through the concerted efforts of human leaders and smart systems. In this world, the security review is often visualized exactly like the image above.

Translated, there’s a relatively small number of individuals who engage with a large number of teams of varying sizes and spread across different timezones in the organization; with the intent of providing the right amount of security guidance, governance and oversight to their initiatives as they go from whiteboard to production. This includes the entire gamut of engaging around security policy requirements, security testing and approval of code / resources intended for wide distribution, identifying risks and escalating exceptions; and embedding the appropriate set of controls in a manner that does not impact usability while enforcing an acceptable level of risk over the entire environment.

Over the many moons I’ve spent doing this thus far, here are the top five comments I’ve heard while in meetings centered around security reviews of business initiatives, applications, external vendor selection and related efforts:

Too late in the game

When you hear this, try to settle in for what could be a very uneasy meeting where everyone is wondering if the security team is going to find and throw a monkey wrench in the gears that have already been assembled, mounted and oiled. Typical causes:

• The security team was brought in late
• It was a skunkworks effort that started small and has now picked up steam
• The security team dropped the ball on meeting with the right folks / teams in time
• Promises have been made to an important audience regarding delivery, and the variable of risk mitigation efforts wasn’t factored into the plan

An elegant solution, as most elegant solutions do, requires some finesse and tact in creatively managing expectations and focusing the team around the intellectual property that could be lost through unidentified and unmitigated risks across the new environment. Things you could try:

• Go back to the data classification to identify data handling requirements
• Get a sense of a breach aftermath from the project team
• Identify any regulatory or related compliance considerations that impact the outcome
• Get formal commitment around completion of risk identification and mitigation activities before the major release / time window
• Present the project team with an option to formally accept the risk of flying without pre-flight check

Things get better if you’re using technology that can provide instant-on value in terms of application / infrastructure / code security reviews towards giving the project team some tangible measures of security quality and perhaps a to-do list in terms of risk mitigation that also lets them visualize and plan for the effort involved.

On the People-Process-Technology scale, this one is all about people and technology; since the process obviously experienced some disconnects or failures. Delivering a solid win from the security perspective here would need a good mix of pragmatic attitudes and agile technology delivery. Doing this well could also drive awareness about the process in a manner that the business would factor into their timelines going forward.

We have already picked a vendor

Translated:

• Security is not our problem
• Our mind is made up about the specifics of the technology deployment we’re going to use

Au contraire, leveraging a third party technology may need extra attention from a security perspective. Questions to consider include:

• Is the third party going to receive, generate, copy or aggregate data that could be considered confidential by the organization?
• Is the third party going to interact with customers?
• Is the third party going to have early access to product collateral or other relevant news release information?
• Is the third party technology vetted by internal security testing cycles?
• Does the third party have any external / independent security assertions?
• Does the third party have any history of data breaches or other failures in information security?
• Does the third party meet the security requirements of any regulatory or other geo-specific compliance mandates?

It is very important to have shared vision around the third party’s security posture and its alignment with the organization’s risk appetite. Requirements to enforce security controls over the relationship should be agreed upon as a part of the contract process; and both parties should have a clear understanding of how security events will be detected, responded to and escalated by the third party. Customer notification is also a major concern when it comes to third party security breaches.

The process of selecting a third party technology to meet internal needs should ideally involve security from the RFP / RFI process; and should make security requirements a significant factor in the assessment of technology candidates as they map to business requirements.

On the People-Process-Technology scale, this one is about process and technology more than people. It is important to be able to show that this is a standardized process that applies to all third party relationships towards getting all external risk to the organization on the same scale; as well as leverage the right kind of security assessment process / technology that facilitates quick informed risk decisions.

People have changed

Loosely translated, this could mean any or all of the following:

• The right contact didn’t communicate this up / around to the right team(s) at the right time
• We didn’t know that we had to involve the security team
• Risk appetites have changed
• Turnover within the team has led to a few balls being dropped

This one can be interesting to watch as it pans out. New people bring new ideas, and new ideas are always good for any process or organization. New staff brings in a great wealth of experience and expertise, classical as well as organic; and the security team should spend the cycles to partner with these changes along the guardrails of corporate security policy and requirements. Typically, going up the chain with the right level of risk assessment and framing with regards to an impact to the brand will help move the process along to a place where the appropriate level of security diligence is done; but that has to be tempered with the knowledge that this is a great opportunity for the security team to forge new relationships with the business.

On the People-Process-Technology scale, this one is all about people. Finding the right security champions and aligning with their pace around security quality can work wonders for the internal security brand. Identifying those with an aptitude for security, at all levels in the organization, should be a constant initiative for those engaged with the security program. The best hackers are those who know the system best, and turning the “insider” paradigm on itself can offer great benefits for security.

No intellectual property

This one can be a mixed bag. To continue the thought from above, the ones closest to the domain are typically the ones who understand the system best, and are thus the ones with the best opinion on the risk of data loss.

However, they are also motivated to get it off the ground; and their proximity to the solution can desensitize them to the value of the data being discussed during a security review.

When faced with “There is no intellectual property in this solution”, here a few questions I lead with:

• Is the solution / partner going to create data that could be considered intellectual property at an atomic and/or aggregate level?
• Is the solution / partner dealing with data that contributes directly to our product or services?
• Is the solution / partner enabling our workforce to create intellectual property or any other outcomes that could be conducive to our competitive edge?

Teasing these details out allows the enforcement of the right kind of security controls in the proposed solution – from technology to supporting business processes.

On the People-Process-Technology scale, this one is about people and technology. Having the right kind of conversations with the right subject matter experts and organizational leadership can allow security to have the appropriate influence in terms of increasing awareness as well as driving change in the final deployment. In the competitive markets that most of us are in, every bit of edge counts towards differentiating our product from the next; and building security into the brand goes a long way towards enhancing market value.

No impact to the business

Typically, this is a high-level risk assessment and offhand assertion offered by someone who isn’t as close to security as the security team. Most of us have learned the hard way that social engineering and dedicated surveillance over the most benign of technologies and processes can result in a clever intrusion and subsequent loss of trust with the customer. The examples are endless – Target’s HVAC system, Point-of-Sale terminals with franchised outlets, and so on..

I summarize it this way: If there were no impact to the business, would / should you be doing this at all?

On the People-Process-Technology scale, chalk up another one for people. Security teams are maligned for selling FUD and it is a fine line between “soft benefits” and “hard benefits”, or, as others would put it – between conjecture and ROI. Finding the right set of people who can help frame the risk to the right levels in the organization towards subsequent mitigation efforts; or formally accepting that unmitigated risk – takes a lot of patience. However, ten times out of ten, it is time well spent.

Those were the top five. Because you stuck around for so long, here’s the bonus tip:

It’s political

Part advice, part stonewall; this one typically brings security conversations to a standstill at many levels in the organization. It conjures up visions; not all of which are rosy. Its always interesting when this comes up, and the context that it comes up in; and to see the ripple effect around the room as it descends. When faced with this one, I’d say – give it a day and change the venue. If that fails, change the audience. But, there really is no textbook answer for this one.

On that happy note – enjoy your next security review meeting!