Skip to content ↓ | Skip to navigation ↓

Losing sensitive company data on your watch is a very bad thing, especially true if your data was stolen by cybercriminals or your competitors. You don’t want to be that guy in the executive office with the albatross around his neck breaking the bad news.

Unfortunately, if your IT organization is structured like the majority of small to mid-sized businesses (SMB’s), sending your security officer as the messenger is not an option. You don’t have one. You are not only responsible for information technology and systems, it’s your job to protect them. But what exactly does that responsibility mean?

Interpretations I hear generally boil down to “protecting data and systems.” Yes, that is what you should be doing but NOT how you should approach the objective. If my business had an IT leader (official title: CIO, IT Director or other) their position description would explicitly include responsibility for managing IT risk to a level which is acceptable to the business.

Furthermore, I would hold my IT Director’s feet to the fire while they justify their information security investments and prove that their information security initiatives address the most significant risks to the organization’s assets. In general, most non-IT executives perceive security as a necessary evil, at best.

On the contrary, executives make risk-based decisions all the time. In my experience, SMB IT Directors too commonly take a “security technology du jour” approach. Worse yet, their information security decisions are based on a very limited and un-scrutinized subset of information sources as input to an ad-hoc information security approach.

This approach always leaves gaps, resulting in a weak security posture which is easy prey for even “opportunistic” and mediocre attackers, let alone skilled marksmen. Many times this haphazard approach not only leads to under protecting in some areas (assets, locations, threat vectors, defending against specific threat actors, etc.), it also results in overprotecting (and therefore, overspending) other areas.

In this post, I’m going to guide you to a risk-based information security path for your business. Of course, you can’t chart directions without knowing your destination. Case in point, we must first determine our targeted security posture (i.e. what is and what is not acceptable risk to our company), prior to analyzing which path is appropriate for our IT organization to take.

With that baseline understood, we then need to explore our information systems and technology to find the gaps that expose our business to risk. At that point, I can show you how to leverage industry frameworks as a compass that you can use to transform the risk information you learned into information security decisions.

Be aware, without a solid understanding of your business and how your information systems support mission critical business functions, down to the associated data flows and storage of sensitive data, you’ve digressed to an IT security approach which is blind to risk. Business information is a fundamental prerequisite to a risk assessment.

From a high level, the risk assessment process is simple and unconditionally consistent.  By determining gaps in our security coverage, probability of exploitation and impact of loss, we can calculate risk. The findings from our risk assessment will lead to our development of a custom implementation roadmap, which will be based on risk, effort and resources.

Since most SMB’s basically take an ad-hoc approach to protecting information systems and data, the primary focus of the initial phase of the remediation roadmap is commonly the development of a formal Information Security Program (ISP). The risk assessment concept is reasonable to most IT Directors. Investing in a risk assessment for their organization is another story: “I know we need security technology x and y. I only have budget for x and y. I can’t spend my budget on a risk assessment and still pay for x and y.”

My theory is that for many IT leaders budget is not the primary cause for rejecting the risk assessment. Secondary Responsibility Syndrome (SRS) is the root cause of most information security failures under the watch of IT leaders.

Over time, as I have observed employee behavior in general and my analysis of their approach to assigned responsibilities, I’ve become aware of a common trend:

Educated and motivated employees typically planned, researched and organized their approach to effectively meet the objectives and goals of their primary responsibility. Conversely, their approach to any other responsibilities (those that fall outside the scope of their primary responsibility) is drastically weaker (a combination of ad-hoc and reactive one-off decisions).

There is no shortage of challenges that IT leaders encounter while trying to remain motivated and focused in their quest to protect corporate information assets. It has been my experience that some of the most brutal mental challenges encountered, were a result of the introduction of additional hurdles after a highly challenging and apparent single hurdle has been overcome.

Consider my real world case in point. Alias “Speed Racer,” without hesitation and without regard for location (Midwest) or season (winter), I opted for the Mustang at the Hertz rental counter. The only real challenge between the airport and my client was an icy hill. My first attempt to ascend failed miserably.

Through trial and error, it became evident that I needed a long straight runway temporarily void of cross traffic so that I could gain the speed and traction necessary to climb to the plateau where the road flattened out. I refused to quit. Instead, I simply retreated further and waited longer.

On about the fourth or fifth run, I made it. As my Mustang leveled out on the flattened road my joy was crushed by the sight of the road almost immediately curving 90 degrees and then within a few yards presenting another icy hill (i.e. unexpected and void of a long runway).

Image courtesy of Shutterstock
“The first icy hill was a lack of information security expertise. The second icy hill was budget.”

In my analogy, the first icy hill was a lack of information security expertise. The second icy hill was budget. Businesses have a limited amount of capital; numerous other initiatives are competing for that same capital.

Typically, initiatives requesting budget are presented to the executive team as opportunities to assist in meeting business objectives; those objectives roll up to more general and generic goals, such as increased revenue, increased market share, etc.

Why do businesses invest in IT? Because IT enables the business to meet their objectives. Recall that executives, especially those other than the CIO, commonly perceive security as a necessary evil, at best. If you request budget for IT security, in essence you are begging for corporate funding on non-productive, non-revenue driving technology, which you claim will prevent bad events from occurring.

Yet, you can’t provide any solid evidence that these events threaten your company’s IT assets or that your current technology can’t protect the assets it accesses. Conversely (from the Department of Redundancy Department), executives understand risk. Many of their decisions are risk-based.

Although IT systems contribute to corporate objectives, they inherently increase risk. I recommend you leverage the results of your risk assessment as the supporting evidence for your information security business case. The objective of your business case will be to reduce risk attributed to IT to an acceptable level.

Now the budget you request will be perceived as an investment in meeting corporate objectives. That investment will allow your organization to implement information technology that will enable the business to meet their objectives (revenue, market share, etc.) while reducing the risk of those business enabling technologies to an acceptable level.

At this point, let’s assume we’re committed to performing a risk assessment and that management has approved funding. Before we take another step, it’s important to clarify terminology. Confusingly, the term “Risk Assessment” is commonly used with different semantics.

For clarity, I am distinctly specifying that the actual assessment and testing of implemented security controls is a “Security Risk Assessment” (also referred to as a “Security Audit”) which I am NOT addressing in this post. The topic of this post is a high level Risk Assessment that drives an information security program including specific security controls which are implemented to manage the business risk of Information Technology.

We are at a critical junction in our path. Commitment paved our way; execution lies ahead. The bridge from “why” to “how” is process. Since our process is critical, we must ensure it is structured, comprehensive and proven. Be aware that industry approved risk assessment frameworks are available for anyone to use, for little or no cost.

The U.S. Government NIST organization offers SP800-30. ISO 27005, OCTAVE and FAIR are also popular. These are frameworks and therefore allow for customization. Furthermore, the industry recognizes further customized risk assessment methodologies which may blend multiple frameworks.

The Risk Assessment methodology I developed for SMB’s is highly customized yet draws from most major frameworks. Customization is driven not only by the client’s business and information systems, but also indirectly for the SMB IT leader.

I’ve proven through experience that a risk assessment that also specifically addresses IT leadership’s perceptions, concerns, challenges and priorities gains significantly more traction with the IT organization’s leaders. That traction drives IT leaders to take notably more action using the results. Furthermore, by involving IT leadership in the development of the ISP and Roadmap, they are considerably more likely to believe in the ISP, take ownership, adhere to the roadmap and support implementation.

Risk Assessments may be performed qualitatively or quantitatively. Quantitative risk assessments result in specific Average Loss Expectancies (ALE’s) which can be directly compared to information security investments in order to determine projected Return on Investment (ROI).

Quantitative risk assessments are typically very expensive. My methodology follows a quantitative approach. Besides fitting well within SMB information security budgets, it provides IT organizations of smaller businesses with results that IT leadership commonly believes in.

While working on my computer science undergrad at DePaul and taking a liberal arts class, I became aware of an Eastern religion that simply decided not to define their god. This culture basically took the approach “why shoot an arrow at a target so far away, you will never have any confidence whether you hit it”.

Consider that the credibility of a quantitative risk assessment depends on the truthfulness of key metrics such as Average Loss Expectancy (ALE). However, numerous variables are required in the formula to calculate ALE, yet most variables cannot be directly measured precisely and many require extreme scrutiny during information gathering and analysis.

As a result, the effort required to deliver a quantitative risk assessment that is both accurate (in its own right) and comprehensively documented (so that its accuracy is acknowledged by those making decisions based on the results), is truly arduous. However, it’s common for IT organizations of large enterprises to be very complex and decentralized. For these organizations, generalized or qualitative results do not provide enough detail to drive business cases, because either:

  1. The organizational structure of large enterprises is typically composed of multiple layers of management. There is a direct correlation between the number of levels of management and the requirement for metrics to support investment decisions, or
  2. Disparate departments or systems have very much different ALE’s and thus much different security budgets.

In this case, metrics are commonly required by management in order to support uneven allocation of security funding. In general, the cost of a quantitative risk assessment is NOT worth the investment for small or even many medium sized businesses. Organizations of this size typically fare well with a moderate risk assessment investment that:

  • Leverages industry standard baselines
  • Relies on realistic and up to date information regarding the threat landscape
  • Addresses the uniqueness of the assessed business and IT organization
  • Can confidently determine relative risk without requiring endless hours of effort and agonizing detail.

Regardless of methodology, all risk assessments determine gaps in protection that result in risk, along with recommendations to remediate those gaps and manage risk. Since many SMB’s lack a formal information security program, ISP development (or the formalization and improvement of the existing security controls and security management) is a primary recommendation and first phase roadmap initiative. If the IT organization already has a formal ISP, the risk assessment results are leveraged to refine the ISP along with remediating control gaps.

Be aware that developing the ISP is not the first priority. The highest priority is remediating the gaps/vulnerabilities that result in the greatest risk. Those with the quickest and least expensive remediation lead that pack.

A Risk Assessment is a crucial Risk Management activity of every organization, regardless of size or any other factor. The results of a Risk Assessment determine the organization’s Information Security Program. Information security has suffered negligence at small and even mid-sized businesses for too long. At the core of the problem is a lack of resources and expertise in organizations that lean on IT staff for security.

During my “No Info Sec Staff? No Problem.” Session at BSidesLV on Tuesday August 5, I will articulate the unique information security and risk management challenges of SMB IT leadership, and share an overview of my comprehensive methodology along with actionable best practices. During that session, I will frame the risk assessment concept into my holistic approach to managing risk as an SMB IT leader.


About the Author: Anthony Czarnik’s security experience covers the roles of security engineer, project manager, partner/channels manager, practice manager, marketing and business development, giving him a perfect 360 degree background with which to lead an information security firm. His initial role was pre-sales engineer for SenSage, a SIEM vendor, where he designed and developed the Cerner HIPAA prototype implemented at Kansas University Medical. He then joined Klocwork, an application security and quality development platform vendor. Czarnik integrated Klocwork into clients’ S-SDLC, designed and led an e-learning courseware development project, and then after managing an information security practice for five years, he founded Czartek, an information security firm. Previously Czarnik has presented at the Chicago chapters of Cloud Security Alliance, Security Meetup, Software Quality Improvement Process (SPIN), Mobile Security Meetup and numerous corporate webinars, and he also published an article on software security and the S-SDLC in the international publication hackin9.


Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.


Related Articles:



picCheck out Tripwire SecureScan™, a free, cloud-based vulnerability management service for up to 100 Internet Protocol (IP) addresses on internal networks. This new tool makes vulnerability management easily accessible to small and medium-sized businesses that may not have the resources for enterprise-grade security technology – and it detects the Heartbleed vulnerability.


picThe Executive’s Guide to the Top 20 Critical Security Controls

Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].


Images courtesy of ShutterStock