Tag Archives: security

Solving “Big Problems” in Security by Building a Service Model

Remediating strategic security concerns can be very difficult, particularly in large organizations with diverse and rapidly evolving product lines. While security is critically important for every part of an organization, individual security risks are not necessarily the most urgent problem to solve for all teams at the same time.

That means our ability to effect widespread change on a reasonable (to us) timetable can be a real struggle. Oftentimes, security teams will fail because they tried to solve all of the world’s problems at once.

At first brush, it makes sense to go after the problem everywhere it exists, considering economies of scale and all. Unfortunately, that doesn’t translate so well when attempting to push work on teams with competing priorities. “Fix this now” is not really an effective motivator.There is another way though that works particularly well for the “BIG” problems, and that’s developing a service model that teams can take advantage of on a timetable that works well for them.

Metrics Develop Interest

If you can’t measure it, you can’t sell it. Regardless if your “big problem” is log management, threat management, or identity access management you can measure it specifically for every team in your organization. Some may be successful, others may struggle, but if you start measuring it regularly and effectively you can demonstrate a problem that can be solved.

Capabilities Solve Problems

Tools are not solutions (no matter how much your vendors may insist otherwise). Solutions are principally capabilities an organization must develop to evolve. Other teams in your organization have no idea what any particular tool does for them, and they have no reason to retain that information if you explain it to them.

Instead, develop a story around the capabilities you want to deliver as a service that addresses the specific problem your organization has. Remember your metrics? Those are now riding shotgun on the road to risk remediation. Keep them handy and keep them coming, month after month. Trending data is beautiful thing!

Service Models Are Tangible

A service needs to be a tangible thing. Would you buy a service from Amazon, Google, or Microsoft if you they couldn’t demonstrate it to you? Neither would others in your organization you are trying to sell to. You must be able to clearly show how the capabilities your are proposing will not only directly affect the metrics you are delivering (i.e. reduce risk), but also show how it will improve the management of that team’s solution. Good security practices often result in big operational wins.

Operationalization is key. There should be a clear path (in the form of a process flow) from service request to service fulfillment. You should also be able to demonstrate how the management of the service will be maintained over time.

That also means clearly understanding the financials. Gaining executive approval to deliver a service in this way is largely dependent on demonstrating a firm understanding of what it will cost to establish the service and maintain the service, as well as a pricing model to calculate how much it will cost to onboard typical use cases. You can demonstrate a positive cost/benefit ratio by highlighting the operational benefits.

….and keep it simple! Your target audience needs to know what you are doing for them, not how you are doing it for them. Keep it high level.

Market the Solution

At this point, you have trending metrics creating market demand and a very consumable solution with a clear cost model. The marketing is practically done for you, but there is still real work to be done. The most effective thing you can do is begin to socialize the solution across the organization in a very positive way and ensure your new capabilities are already on roadmaps around the organization.

Developing a service model like moves Information Security from being a source of unwelcome work to a solution provider that can demonstrate real, tangible value to the organization in a very consumable way.

Best of all, taking a measured approach such as this generally leads to teams taking a fresh look what caused this “big problem” with their solution in the first place. Typically, this will result in the streamlining of accounts, systems, or processes in order to reduce the cost of on-boarding the capabilities you are offering.

This is a BIG security win, a BIG operational win, and a BIG financial win!

Was this interesting or helpful? Like, Comment, or Share and I’ll write more.

Closing Open Doors by Bringing Vulnerabilities to Resolution – Six Essential Questions

New vulnerabilities are discovered every day,Vulnerabilities and they are an intruders’ best friend. It’s a bit like a burglar finding the door
unlocked and wide open; he’s going to have a really easy day at work and you’ll be wondering for a long time why you left it open.

Therefore, it is absolutely critical to resolve them as soon as possible before they are exploited.

A vulnerability report can be a bit daunting though, especially for a complex solution which relies on many different technologies.  Over the years, I‘ve found that asking these six questions can help bring even the most obscure vulnerability to resolution.

Question #1: Can I remove/upgrade the vulnerable software?
Many times we find a solution is installed with supporting software components that may no longer be required. If this is the case, the easiest way to resolve the vulnerability is to completely remove that component. Best of all, once removed, you no longer have to worr
y about new vulnerabilities presenting themselves in the future for this piece of software.

There are also times that version upgrades may be available for these software components. Upgrading those components to the latest version not only resolves the vulnerability, but also ensures you are working with the latest and fully supported version of that software.

Question #2: Would a configuration change resolve this vulnerability?
Some vulnerability’s cannot be patched, and can only be corrected with a configuration change to the system.

A good example of this is SSL 3.0, an encryption standard used by many web services that has recently been found to be insecure. Changing the configuration of the web service to use TLS 1.2 not only resolves the vulnerability, but also brings the solution in to compliance with PCI and other security standards.

Question #3: Can a security patch be applied?
If the affected software is still supported by the developer, a security patch may be required. If this is the case, submit a request to have the patch installed after testing it thoroughly with your solution.

Question #4: Is the supporting data accurate?
Vulnerability scanners are not perfect, and false positives are a real possibility. Fortunately, the vulnerability report will contain supporting data that was used to determine the presence of a vulnerability. If you suspect a false positive, validate it by performing a manual inspection to invalidate the results the vulnerability scanner provided. If you confirm that it is indeed a false positive, submit evidence to your vulnerability management team to have the finding removed from the report.

Question #5: Can the vulnerability be mitigated?
If the software is current, and the developer does not have an expected release date for a security patch, an alternative method may be required to bring this vulnerability to resolution. This may involve firewall rules to restrict access, or the disablement of non-essential services that would be required for an attacker to take advantage of the vulnerability. Once mitigated, submit evidence of the mitigation to your vulnerability management team to have the finding removed from the report.

Question #6: Is an exception warranted?
There are rare circumstances where a vulnerability must be accepted.  It may be a business process that relies on an end-of-life solution, or the vendor is unable/unwilling to supply a security patch. Whatever the case, when a vulnerability must be accepted it is essential to raise awareness through your vulnerability governance processes. The appropriate security teams can then work to determine what other defenses could be leveraged in to limit exposure. This may involve segmenting the solution from the rest of the network or increasing the visibility of anomalous activity on the solution.