I love playing Pictionary! I am not the best illustrator in the world, but that is what makes it so much fun. It can be a difficult game, especially when playing with individuals that think or interpret things differently than you. One of the keys to being successful in this game is to think like your teammates do. You have to draw — or illustrate — in a way that they can interpret the point you are getting across. This is the challenge. I share this with you, because playing Pictionary is a lot like building a business case. Defining the need of the business case requires you to translate the need in a way that management (the decision makers and your team members) can understand and take action against.
In this third installment of my blog series around Building a Business Case for DDoS, I want to focus on the second step; Illustrating the Business Implications. In last week’s blog, I focused on being able to effectively communicate your business needs and pains. The language of business is full of nuance and requires certain finesse. To support your case, you also should be able to illustrate why you have a need. In the case of DDoS mitigation and protection, you can achieve this through showing the impact of an attack in multiple ways:
- The Reference Architecture
- The Attack in Action Map
- The Cost/Loss Calculator
There are many different ways in which you can illustrate the business need, but let’s dive into the three I mention.
The Reference Architecture
Many organizations need to understand where a solution resides within a corporate infrastructure. By understanding where a solution sits helps to define the purpose and management of a technology. Why a reference architecture has value in this discussion is to create domain ownership and an understanding. By showing where a DDoS solution would reside in the corporate architecture, you can steer the conversation into a couple of areas. You can discuss the nature of a DDoS attack, and how it can bypass other security measures that are already in place. A reference architecture can also provide the team with insight into the advanced nature of a DDoS attack. Most organizations view a DDoS solution and the respective attack as a network operations issue, but these attacks have evolved. In most cases, they are often part of a greater campaign, or used as a smokescreen for more nefarious activity. Using these examples, you can begin to show the complexity of a DDoS attack, and how network operations must work with security operations to ensure effective protection. This leads to my next illustration example.
The Attack in Action Map
Showing the team how a modern day DDoS attack can infiltrate your current IT environment is effective. However, you must walk a fine line between illustrating the technical aspects of the attack versus the business implications. Depending on whom you are presenting to, the end game is to show business impact, not bad IP addresses. Showing a management team how an attack can bypass traditional perimeter-based security technologies, and insert botnets or other viruses onto application servers can be a very large eye opener. You can also show how application-layer DDoS attacks can oftentimes go undetected until it is too late because the capacity of traffic used to attack an application is significantly smaller than a volumetric-based attack. The most profound way you can illustrate the impact of a DDoS attack is to use personal, or company-specific, examples. If the company has already experienced attacks, this is your time to talk about them.
The Cost/Loss Calculator
A picture is worth a thousand words, but in business it should go, a picture is worth a thousand dollars…if not more. Most business decisions are made or impacted by cost. No technology decision is made without financial scrutiny. There are a couple ways of illustrating the financial impact of DDoS to business decision makers. When presenting the costs of DDoS, it is best to represent the costs of implementing a DDoS solution while comparing it to the costs associated with doing nothing, meaning the anticipated loss in revenue and resources when an attack occurs. The key is to make sure that the costs that are being estimated are based on realistic values, and can be agreed on without significant debate. Again, showing justification based on real experience is the key.
Building a business case is often longer in its process than obtaining approval and implementing the solution. There are many decision makers, influencers and stakeholders involved, and an effective plan can communicate and illustrate the impact and need to each of them. So when getting ready to build the business case, get out your sharpie marker, and practice your drawing skills. Illustrating the business implications of a DDoS attack for your business environment may be the single most important facet to accelerating the opportunity with your key decision makers.
The post Illustrating the business implications appeared first on Arbor Insights - Our People, Products and Perspective.