The Scale Cube: Achieve Security Through Scalability
May 14, 2019 | Posted By: James Fritz
If AKF Partners had to be known for one thing and one thing only it would be the Scale Cube. An ingenious little model designed for companies to identify how scalable they are and set goals along any of the three axes to make their product more scalable. Based upon the amount of times I have said scalable, or a derivative of the word scale, it should lead you to the conclusion that the AKF Scale Cube is about scale. And you would be right. However, the beauty of the cube is that is also applicable to Security.
The X-Axis is usually the first axis that companies look at for scalability purposes. The concept of horizontal duplication is usually the easiest reach from a technological standpoint, however it tends to be fairly costly. This replication across various tiers (web, application or database) also insulates companies when the inevitable breach does occur. Planning for only security without also bracing for a data breach is a naive approach. With replication across the tiers, and even delayed replication to protect against data corruption, not only are you able to accommodate more customers, you now potentially have a clean copy replicated elsewhere if one of your systems gets compromised, assuming you are able to identify the breach early enough.
One of the costliest issues with a breach is recovery to a secure copy. Your company may take a hit publicity wise, but if you are able to bring your system back up to a clean state, identify the compromise and fix it, then you are can be back on your way to fully operational. The reluctant acceptance that breaches occur is making its way into the minds of people. If you are just open and forthright with them, the publicity issue around a breach tends to be lessened. Showing them that your system is back up, running and now more secure will help drive business in the right direction.
Splitting across services (the Y-Axis) has many benefits beyond just scalability. It provides ownership, accountability and segregation. Although difficult to implement, especially if coming from a monolithic base, the benefits of these micro-services help with security as well. Code bases that communicate via asynchronous calls not only allow a service to fail without a major impact to other services, it creates another layer for a potential intruder to traverse.
Steps that can be implemented to provide a defense in depth of your environment help slow/mitigate attackers. If asynchronous calls are used between micro-services each lateral or vertical movement is another opportunity to be stopped or detected. If services are small enough, then once access is gained threats have less access to data than may be ideal for what they are trying to accomplish.
Segmenting customers based upon similar characteristics (be it geography, spending habits, or even just a random selection) helps to achieve Z-Axis scalability. These pods of customers provide protection from a full data breach as well. Ideally no customer data would ever be exposed, but if you have 4 pods, 25% of customer data is better than 100%. And just like the Y-Axis, these splits aid with isolating attackers into only a subset of your environment. Various governing boards also have different procedures that need to be followed depending upon the nationality of the customer data exposed. If segmented based upon that (eg. EU vs USA) then how you respond to breaches can be managed differently.
Now I Know My X, Y, Z’s
Sometimes security can take a back seat to product development and other functions within a company. It tends to be an afterthought until that fateful day when something truly bad happens and someone gains unauthorized access to your network. Implementing a scalable environment via the AKF Scale Cube achieves a better overall product as well as a more secure one.
If you need assistance in reaching a more scalable and secure environment AKF is capable of helping.
Subscribe to the AKF Newsletter
5 Statements That Should Get CISOs Fired
March 6, 2019 | Posted By: Marty Abbott
Our typical assessment goes something like this: We spend 1.75 days with an energized product team comprised of engineers and product managers. We feel the passion and engagement of the team, and we see the signs of stress the team endures in trying to meet product delivery schedules. Then we meet the security person. The person is not very stressed, does not have delivery goals and seems to steal the energy from the room.
This is an angry post. I won’t apologize for that. I’m fed up with the ridiculous way that most CISOs approach security, and you should be too. The typical approach, in more than 80% of the companies with which we work, results in slow time to market, increased response time for transactions, higher than necessary cost, lower than appropriate availability, and no demonstrable difference in the level of security related incidents. Put another way, most CISOs reduce rather than increase shareholder value.
Here is a handy tool to identify value-destroying CISOs. We’ve compiled 5 common statements uttered by CISOs out of touch with the needs of the corporation, customers and shareholders. Each of these assumes that the CISO both believes the statement and acts consistently with the statement (a high probability chance). Each statement is followed by why it is bad, what it is costing you, and what (besides replacing the person) you should do.
“No, we can’t do that”
Wrong answer. The purpose of security is to help move the company towards the right business outcome, as quickly as possible, with the right level of risk for the endeavor. This means that in some cases, where the probability and impact of compromise is low, we simply do not apply much “security” to the solution. In other cases, where probability and impact is high, we put measures in place to reduce probability and impact.
We never say “No” to an ethical outcome. Rather than saying “No” to a path, we attempt to ensure the path includes the right level of risk adjustment to make it successful.
The right answer: “That may work if we make a few modifications to help reduce the following probability of an incident, and reduce the impact of an incident should it occur. Here’s how my team can help you”.
“My job is to keep us out of the paper”
Incomplete, and as a result, incorrect answer. The role of security is to ethically maximize profits, by ensuring that risk is commensurate with the endeavor. A great security team helps decrease the probability of incidents and decrease the impact of an incident should one arise. This in turn helps ensure that profits achieve an appropriate level. “Keeping us out of the paper” makes no reference to the fiduciary responsibility of providing returns to shareholders. It’s further not a path to that responsibility, as there is no tie to enabling or maintaining profitability. Hell, if you want to achieve this goal, all you have to do is go out of business!
The right answer: “My job is to ensure an appropriate risk approach to stakeholder return – specifically through helping us to achieve an appropriate risk posture for our initiatives that meets our time to market, revenue and profitability objectives”.
“We have to work the process” or “Put in a request – we’ll review it”
Wrong answer. Security isn’t a “team” in and of itself because it can’t “score” and “win”. Security is part of a larger team responsible for delighting end customers such that we can ensure appropriate profitability through superior and appropriately secure offerings. To that end, security needs to adopt an agile mindset – specifically “individual interactions over processes and tools” and be embedded within the value creation teams that are the lifeblood of a company. Further, product and operational teams need to “own” and be accountable for the risk associated with the solutions they create and maintain. Software and servers need to be secure consistent with the needs of the business and end users.
The right answer: “Let’s get together immediately and make this work. Furthermore, how could I have ensured we had folks involved earlier to help you get this out faster?”
“My job is governance” or “We need the right governance model”
Wrong answer. The implication of the above statement is that the value the security team provides is in judging the work of others and ensuring compliance. The best security teams understand that compliance is best achieved through embedding themselves within product teams – not sitting in judgement of them during the process. The fastest and highest value creating teams are those that understand and have the right tools to accomplish the necessary outcomes embedded within their teams (read the related white paper here).
The right answer: “We embed people in teams to get the right answer quickly and get the product to market faster. Good governance happens in real time and in many cases can be automated within the product development lifecycle (CICD pipelines for instance).
“We have to slow things down a bit”
Wrong answer. If you have a compelling growth business with a big vision, you are going to attract competitors. If you have competitors, getting the right solution to market quickly is critical to your success. No one “wins” by playing only defense or by being just “careful”. You win by making the best risk measured decisions quickly and releasing a good enough product before your competitors.
The right answer: “We have to figure out how to make the right decisions early without slowing down our delivery.”
Another way to determine if you have the “right” security team and correct security leader is to evaluate the number of security related engineers embedded within teams relative to the number of people evaluating approaches or “governing”. If the number of “governing” employees exceeds the number of embedded employees, you have a problem. Ideally, we want a very small number of “brakes” (governance) and more security product “gas pedals” (embedded). The latter results in better decisions and better product security in real time. The former results in delay, overhead, and an ivory tower.
We perform dozens of security assessments and technical due diligence reviews every year. Contact us and let us help!
Subscribe to the AKF Newsletter
The AKF Difference
December 4, 2018 | Posted By: Marty Abbott
During the last 12 years, many prospective clients have asked us some variation of the following questions: “What makes you different?”, “Why should we consider hiring you?”, or “How are you differentiated as a firm?”.
The answer has many components. Sometimes our answers are clear indications that we are NOT the right firm for you. Here are the reasons you should, or should not, hire AKF Partners:
Operators and Executives – Not Consultants
Most technology consulting firms are largely comprised of employees who have only been consultants or have only run consulting companies. We’ve been in your shoes as engineers, managers and executives. We make decisions and provide advice based on practical experience with living with the decisions we’ve made in the past.
Engineers – Not Technicians
Educational institutions haven’t graduated enough engineers to keep up with demand within the United States for at least forty years. To make up for the delta between supply and demand, technical training services have sprung up throughout the US to teach people technical skills in a handful of weeks or months. These technicians understand how to put building blocks together, but they are not especially skilled in how to architect highly available, low latency, low cost to develop and operate solutions.
The largest technology consulting companies are built around programs that hire employees with non-technical college degrees. These companies then teach these employees internally using “boot camps” – creating their own technicians.
Our company is comprised almost entirely of “engineers”; employees with highly technical backgrounds who understand both how and why the “building blocks” work as well as how to put those blocks together.
Product – Not “IT”
Most technology consulting firms are comprised of consultants who have a deep understanding of employee-facing “Information Technology” solutions. These companies are great at helping you implement packaged software solutions or SaaS solutions such as Enterprise Resource Management systems, Customer Relationship Management Systems and the like. Put bluntly, these companies help you with solutions that you see as a cost center in your business. While we’ve helped some partners who refuse to use anyone else with these systems, it’s not our focus and not where we consider ourselves to be differentiated.
Very few firms have experience building complex product (revenue generating) services and platforms online. Products (not IT) represent nearly all of AKF’s work and most of AKF’s collective experience as engineers, managers and executives within companies. If you want back-office IT consulting help focused on employee productivity there are likely better firms with which you can work. If you are building a product, you do not want to hire the firms that specialize in back office IT work.
Business First – Not Technology First
Products only exist to further the needs of customers and through that relationship, further the needs of the business. We take a business-first approach in all our engagements, seeking to answer the questions of: Can we help a way to build it faster, better, or cheaper? Can we find ways to make it respond to customers faster, be more highly available or be more scalable? We are technology agnostic and believe that of the several “right” solutions for a company, a small handful will emerge displaying comparatively low cost, fast time to market, appropriate availability, scalability, appropriate quality, and low cost of operations.
Cure the Disease – Don’t Just Treat the Symptoms
Most consulting firms will gladly help you with your technology needs but stop short of solving the underlying causes creating your needs: the skill, focus, processes, or organizational construction of your product team. The reason for this is obvious, most consulting companies are betting that if the causes aren’t fixed, you will need them back again in the future.
At AKF Partners, we approach things differently. We believe that we have failed if we haven’t helped you solve the reasons why you called us in the first place. To that end, we try to find the source of any problem you may have. Whether that be missing skillsets, the need for additional leadership, organization related work impediments, or processes that stand in the way of your success – we will bring these causes to your attention in a clear and concise manner. Moreover, we will help you understand how to fix them. If necessary, we will stay until they are fixed.
We recognize that in taking the above approach, you may not need us back. Our hope is that you will instead refer us to other clients in the future.
Are We “Right” for You?
That’s a question for you, not for us, to answer. We don’t employ sales people who help “close deals” or “shape demand”. We won’t pressure you into making a decision or hound you with multiple calls. We want to work with clients who “want” us to partner with them – partners with whom we can join forces to create an even better product solution.
Subscribe to the AKF Newsletter
The Elusive Data Breach
November 15, 2018 | Posted By: James Fritz
“but in this world nothing can be said to be certain, except death and taxes.”
...and data breaches. Given the era that Benjamin Franklin lived in the concept of a data breach was far from any possibility. But in the world we live in it is a certainty. Death, taxes and data breaches. Welcome to the 21st Century.
So how did we get here? The death and taxes is for someone else to explain, but the data breach I will help flesh out. The following article will begin to explore the world we live in where we know data breaches are not something you hope never happens, but something you prepare for to happen. Following this article, in the coming weeks I will explore what can be done when the inevitable does occur.
Data Breaches in the 21st Century
“My system is completely secure,” says the guy who is already breached and just doesn’t know it.
Why is a data breach such a certainty in these days? It comes down to four areas: similarity, interconnections, users and motive.
In 2015 Windows had a great marketing plan to upgrade as many older OSes to the current release: offer the upgrade for free. Issues with upgrading (or tricking users to upgrade against their will) aside this built a quick base for Windows 10 and quickly allowed Windows 10 to overtake version 7 in December 2017 as the most adopted version of Windows. Couple this with the fact that Windows is one of the highest used OSes and you now have a nicely populated target base.
This isn’t to say that Windows machines are more susceptible than other machines, but that given their popularity and the scheduled release of updates, malicious people are able to identify the weaknesses being patched and target machines that are slower to update. In an ideal world patches would be applied in a timely manner but there always extenuating circumstances that keep this from happening. So now if your POS (Point of Sale) system is several patches behind there is an exploit that can target its weakened state.
Don’t feel like being breached and exploited via the internet? Never get on the internet. Simple answer, but not a feasible one given the world in which we live.
At AKF we have a tenet of Build vs. Buy. From a cost perspective it doesn’t make sense to build something that you know very little about if a 3rd party already offers it for a reasonable price. But cost isn’t the only decision to weigh when it comes to connecting to a 3rd party. Risk is another major factor. Is the interaction between your system and the 3rd party enough to help insulate you from their potential compromise? Integrations through API usually help solve this issue, but sometimes a more thorough coupling of the software is necessary.
So now being reliant on an additional entity (or even more) in that 3rd party helps create another vector with which to be compromised. And to top it off, you usually don’t have any insight into their security posture. They may be obligated to provide you with quarterly security scans, but that doesn’t mean they don’t turn off their highly vulnerable machines prior to each scan.
Congratulations on having an extremely secure system that doesn’t rely on 3rd parties being secure as well. You are now brought down by an employee who thinks they won a raffle.
If this all sounds like a horrible “Choose Your Own Adventure” then you are in the right mindset. It doesn’t matter what you do to protect your systems because you have Users. This isn’t to say that all Users can’t be trusted but there are degrees to how much trust they should have. And whether inadvertent or purposeful they are an extremely susceptible entry point for a breach to occur. Advanced threats are getting smarter and smarter at crafting emails that get past basic email filters and once opened, create a backdoor for them to access the system. Once persistent call backs are established, all traffic now looks like the User is generating it internally and most security allows User initiated traffic a higher degree of freedom.
Have you ever had a bone to pick with a company and didn’t care about the legal ramifications of what you did? Hopefully not. But that segment does exist. Whether you inadvertently wronged a former customer, at least according to them, or you have something that someone else covets, they are going to move hell and high water to get it. The only thing worse than a malicious actor casting a wide net in the hopes of getting a compromise to stick, is someone specifically targeting your business. It can become an obsession for them.
Maybe they want access to the banking records you protect, or they would just like to see you embarrassed, this is a worst case scenario for a business. Someone who refuses to stop until they compromise your system. They will use everything available, leveraging similarity, interconnections and your Users to gain access.
You’ve Been Breached
Congratulations! You’ve been breached?!? Not really the accolade you were looking for, but one you need to accept. They say the first step is Acceptance, so if you’ve made it this far, you’re where you need to be. Don’t believe you are breached, or will be in the future? Feel free to read the article again and start to really ask yourself if you are secure as you think you are. The above are just small snippets of the overall vulnerability you may have.
-Don’t use Windows? Well Linux doesn’t guarantee not being compromised.
-Not connected to anyone? Possible if you are brick and mortar store that only accepts cash.
-You employ the savviest Users? Everyone makes a mistake from time to time.
-Never upset someone or owned something they could want? You aren’t a business then.
So what comes next? Well for that there is a lot of articles out there explaining how to help shore up your system. One such article comes from our very own Larry Steinberg, Are you compromised? The important thing is to pick an area where you feel that you are weakest at and go from there. More often than not this revolves around user training. But maybe checking off some items from the Australian Cyber Security Centre’s Essential Eight will help.
Ultimately you should have the best ideas on how to help secure your system, but if you find that you may need some assistance looking at you product holistically, with security in mind, AKF can help.
Subscribe to the AKF Newsletter
Are you compromised?
September 14, 2018 | Posted By: Larry Steinberg
It’s important to acknowledge that a core competency for hackers is hiding their tracks and maintaining dormancy for long periods of time after they’ve infiltrated an environment. They also could be utilizing exploits which you have not protected against - so given all of this potential how do you know that you are not currently compromised by the bad guys? Hackers are great hidden operators and have many ‘customers’ to prey on. They will focus on a customer or two at a time and then shut down activities to move on to another unsuspecting victim. It’s in their best interest to keep their profile low and you might not know that they are operating (or waiting) in your environment and have access to your key resources.
Most international hackers are well organized, well educated, and have development skills that most engineering managers would admire if not for the malevolent subject matter. Rarely are these hacks performed by bots, most occur by humans setting up a chain of software elements across unsuspecting entities enabling inbound and outbound access.
What can you do? Well to start, don’t get complacent with your security, even if you have never been compromised or have been and eradicated what you know, you’ll never know for sure if you are currently compromised. As a practice, it’s best to always assume that you are and be looking for this evidence as well as identifying ways to keep them out. Hacking is dynamic and threats are constantly evolving.
There are standard practices of good security habits to follow - the NIST Cybersecurity Framework and OWASP Top 10. Further, for your highest value environments here are some questions that you should consider: would you know if these systems had configuration changes? Would you be aware of unexpected processes running? If you have interesting information in your operating or IT environment and the bad guys get in, it’s of no value unless they get that information back out of the environment; where is your traffic going? Can you model expected outbound traffic and monitor this? The answer should be yes. Then you can look for abnormalities and even correlate this traffic with other activities in your environment.
Just as you and your business are constantly evolving to service your customers and to attract new ones, the bad guys are evolving their practices too. Some of their approaches are rudimentary because we allow it but when we buckle down they have to get more innovative. Ensure that you are constantly identifying all the entry points and close them. Then remain diligent to new approaches they might take.
Don’t forget the most common attack vector - humans. Continue evolving your training and keep the awareness high within your staff - technical and non-technical alike.
Your default mental model should be that you don’t know what you don’t know. Utilize best practices for security and continue to evolve. Utilize external or build internal expertise in the security space and ensure that those skills are dynamic and expanding. Utilize recurring testing practices to identify vulnerabilities in your environment and to prepare against emerging attack patterns.
We commonly help organizations identify and prioritize security concerns through technical due diligence assessments. Contact us today.
Subscribe to the AKF Newsletter
Open Source Software as a malware “on ramp”
August 21, 2018 | Posted By: Larry Steinberg
Open Source Software (OSS) is an efficient means to building out solutions rapidly with high quality. You utilize crowdsourced design, development and validation to conveniently speed your engineering. OSS also fosters a sense of sharing and building together - across company boundaries or in one’s free time.
So just pull a library down off the web, build your project, and your company is ready to go. Or is that the best approach? What could be in this library you’re including in your solution which might not be wanted? This code will be running in critical environments - like your SaaS servers, internal systems, or on customer systems. Convenience comes at a price and there are some well known situations of hacks embedded in popular open source libraries.
What is the best approach to getting the benefits of OSS and maintaining the integrity of your solution?
Good practices are a necessity to ensure a high level of security. Just like when you utilize OSS and then test functionality, scale, and load - you should be validating against vulnerabilities. Pre-production vulnerability and penetration testing is a good start. Also, utilize good internal process and reviews. Keep the process simple to maintain speed but establish internal accountability and vigilance on code that’s entering your environment. You are practicing good coding techniques already with reviews and/or peer coding - build an equivalency with OSS.
Always utilize known good repositories and validate the project sponsors. Perform diligence on the committers just like you would for your own employees. You likely perform some type of background check on your employees before making an offer - whether going to a third party or simply looking them up on linkedin and asking around. OSS committers have the same risk to your company - why not do the same for them? Understandably, you probably wouldn’t do this for a third party purchased solution, but your contract or expectation is that the company is already doing this and abiding by minimum security standards. That may not be true for your OSS solutions, and as such your responsibility for validation is at least slightly higher. There are plenty of projects coming from reputable sources that you can rely on.
Ensure that your path to production is only coming from artifacts which have been built on internal sources which were either developed or reviewed by your team. Also, be intentional about OSS library upgrades, this should planned and part of the process.
OSS is highly leveraged in today’s software solutions and provides many benefits. Be diligent in your approach to ensure you only see the upside of open source.
Need additional help? Contact Us!
Subscribe to the AKF Newsletter
5 Focuses for a Better Security Culture
July 13, 2018 | Posted By: James Fritz
Security culture is one of the hardest aspects of security to get right. Unfortunately, it is also the most important thing for security that needs to be done right. It is so important because your culture has a tremendous impact on a very important aspect of your company, your employees.
Multiple studies have been conducted over the years and the number one cause for breaches is always employees. Whether purposeful or inadvertent, breaches occur and most often traced back to employees. Why would an adversary attempt to gain access to a database by leveraging weaknesses in a webserver when they can just compromise a database administrator? The level of access that employees have make them a rich target.
The security culture of a company is like any other culture: cultures thrive when employees embrace them and fail when they do not. When employees subscribe to the security culture, then ultimately the company becomes more secure because they will become harder targets and in the course of their daily work they will be able to spot a compromised machine or weak password because sloppy security stands out in a healthy and thriving security culture.
Five Areas of Focus to Improve Security Culture:
-“No, however” vs “No”
When a new implementation or modification comes down the line and it doesn’t mesh with security principles, do you say “No” or “No, however”? There is a very distinct difference between these two responses. The first response of just “No” means you have drawn a line in the sand and security trumps whatever is being attempted. The issue with this is that no doesn’t help create productivity and solve the business problem. If you allow security to stand in the way of business then you will soon be looking for a new job. The only true way to be secure is to stay out of business, so security needs to find a way to coexist with business.
If your response is “No, however” then you are off to a good start. There are times when new product may not align with the regulations that are required for your company. And that is ok. It is your job to work with the team and figure out how to best implement what they want and not violate those regulations.
By spending your time shutting down new business ideas for the sake of security, you will quickly realize that no one is coming to you anymore. And that is detrimental for security.
If you’ve never heard groans and sighs as you announce the next round of security training, then you can count yourself part of a very exclusive group of people; People with training that is both engaging and beneficial.
With all the meetings and events that are required in order to keep all the employees going in the same direction, adding more time away from keyboards is never easy. If time away is unproductive then not only is no one learning anything, the company is simultaneously losing money. The topics of discussion need to be relevant and beneficial to the employees and the company.
If you find yourself talking about the latest attack vectors to Red Hat based systems and the majority of your systems are Windows or iOS based then you are going down the wrong path. You need to understand your company and the direction it is going in order to gear you training towards those aspects. Your training can either be productive or unproductive. The more productive it is the easier security is in the long run.
Who is required to be a part of the culture of security? Is your CISO the only one pushing training and recommending that security be brought into development and not considered an afterthought? Or does it go higher?
People are very observant. If they notice that security isn’t embraced by everyone up to and including the CEO then why should they embrace it? Additionally, the most sought-after targets for an adversary are usually the C-level employees. A lot of open source information exists about them and they tend to have a lot of access. So, if the most susceptible employees are not required to be a part of the culture, what reason would someone else have to be a part of the culture?
-Level of Attachment
How attached you are to doing security solely in house is indicative of how quickly it will become stagnant. To think that your company is unique in how it is targeted by adversaries only sets you up for failure. You need to open your doors to third parties or similarly based companies when it comes to security in order to ensure that you are staying relevant with the latest trends and threats that exist.
Unless you are a company that does security for companies, then you are already at a competitive disadvantage for solely performing your own scans. Companies exist with the sole purpose of staying current with the tactics being utilized and then provide you with feedback on how to protect yourself; use them. This isn’t to say that you should completely outsource all security responsibility. Depending on how vulnerable your company is looking at bringing in a third party monthly or quarterly. In between those visits conduct scans internally as well.
Additionally, threats that exist today cast wide nets to see what they can compromise. If you run a deli, chances are the bakery down the street has the same potential to get attacked by the same bad actor. Have your security professionals communicate regularly with them. You aren’t sharing any sort of Intellectual Property by talking about the recent scans or attacks you’ve been seeing. You are helping to create a community that is stronger together against outside attacks.
-Best Business Practices
Some policies you can’t get around. Heavily regulated markets require certain steps be taken in order to secure financial data, health data, personally identifiable information, etc. These policies need to be put into place. This will leave gaps in being secure though. That is where best business practices come in.
Security in an information age isn’t something new. People have been doing it for a very long time. Lists of recommendations, and even steps, exist to help people bridge the gap from insecure to secure. Use these and bolster what you have in place. If something doesn’t pass the “smell test”, then discard. Your policies and procedures should be a living document that is reviewed and updated regularly. If you follow the current trends that exist and keep ingesting the best practices then a lot of the work will be done for you.
This list isn’t all inclusive. Maybe you find yourself better situated in one, or more, of the above aspects. If that is the case, then great. But if you need help in shoring up the above five areas or are looking for additional support on how best to secure your company, AKF can help.
Subscribe to the AKF Newsletter
June 29, 2018 | Posted By: James Fritz
The simplest definition of risk is the probability an incident occurs times the impact of the incident. The higher this number is, the higher the risk. With the identification of risk then comes the method of how to handle risk. The four risk management strategies are mitigation, transference, avoidance and acceptance. Three of these strategies can be utilized by a company that finds itself in the later stages of the Technology Adoption Life Cycle, where they have a solid customer base that is looking for stability. However, only mitigation works for companies that are attempting to enter the market and capture the Innovators and Early Adopters.
What are the Risk Management Strategies?
The four strategies mentioned are:
- Mitigation: Knowing an incident is going to occur and attempting to minimize its impact or probability.
- Transference: Transferring the burden of the risk to someone else. Usually done through insurance.
- Avoidance: Not doing an activity, thereby eliminating the probability of the incident occurring.
- Acceptance: Realizing that you have done all you can and must accept both the impact and the probability of an incident.
As stated earlier, for new products to the market, the most viable option of managing risk is through mitigation. If a company was to avoid the risk, then that would potentially deprecate the product they were trying to bring to market. By transferring a company runs the risk of losing its early customer base when an incident occurs, likewise with accepting the risk.
So how can you handle the risk as a company attempting to attract Innovators and Early Adopters? The answer is in using the AKF Risk Model.
AKF and Risk
In his article, Evaluating Technology Risk Using Mathematics, Geoffrey Weber lays out a finite method of identifying a certain level of risk a company may be at utilizing impact, probability and the ability to detect. This method returns concrete data that would then allow a company to prioritize what risk they intended to manage.
Once you have prioritized your risk and are now determining how to mitigate it, the five main components to the AKF Risk Model can be used. Depending on whether impact or probability was the issue, the below areas can be focused on to mitigate the overall risk.
How to Affect Probability
- Payload Size: By limiting the sizes of change that are introduced to a product, the probability of an incident occurring is limited. This ensures that if an incident occurs it only affects a small aspect of the product.
- Testing: Testing aims to mitigate potential incidents prior to them occurring. Unit testing and code review will not catch 100% of the issues that may arise, but it helps to lessen the probability that something was to occur.
How to Affect Impact
- Fault Isolation Architecture: By utilizing the AKF Scale Cube, Fault Isolation will be built into the product. This helps to mitigate the impact of an incident to just a small percentage of the overall customer base.
- Monitoring: The establishment of proper monitoring provides developers a way to identify issues just prior to occurring, or as they occur. With real-time monitoring an incident can be identified as it is occurring and the company can quickly act to mitigate the impact.
- Rollback: If an incident has occurred, being able to rollback the product helps to lessen the impact. If a stable version of the product exists then that can be implemented while the company identifies what happened with the newer deployment, allowing customers to continue with their interactions.
Where does your company fit in?
If you find yourself with a customer base of Laggards and Late Majority then you have a lot more options for managing risk. Issues that arise through the use of transference, acceptance and avoidance still allow you to maintain solid sales.
If you find yourself with a customer base of Innovators and Early Adopters then you have less options for managing risk. Mitigation is the most beneficial option that is available to you for you to continue to move through the cycle and start to pick up the Early Majority.
If the AKF Risk Model is something you would like to learn more about, feel free to reach out to AKF.
Subscribe to the AKF Newsletter
Tech Due Diligence - 5 Common Security Mistakes
June 28, 2018 | Posted By: Pete Ferguson
In our technical due diligence reviews we conduct for investment firms, we see five common mistakes by both young startups and in well-seasoned companies alike:
Lack of Security Mindset During Development: Security gets a bad rapport for being overkill, costly, and a hindrance to fast growth when security teams fall into the “No It All” philosophy of saying “No” especially when their focus on security overshadows any considerations of what revenue they halt or hinder in saying “No.” This tends to be true when organizations do not share the same risk related goals, or when the security organization feels that it is only responsible for risk alone and not the maximization of revenue with appropriate risk. Good security requires a team effort and is difficult to add into a well-oiled machine as an afterthought. It is much easier to do at the onset of writing code and including checks for security with the automation of testing and QA will ensure security is baked in. Hold developers responsible for security and security responsible for enabling revenue while protecting the company in a common sense approach.
Failing to Separate Duties: Usually as small companies grow larger, everyone continues to have access to everything, and many original employees wear multiple hats. Making sure no one individual is responsible for development to production gains points in other areas like business continuity as well. Separation of duties does not just exist between two employees - the separation can also be created by automation as is the case in many successful continuous deployment/delivery shops deploying directly into production. Automated testing will additionally help with code compliance and quality assurance. Automate access control by role wherever possible and regularly have business owners review and sign off on access control lists (at least monthly). My colleague James Fritz goes into greater detail in a separate article.
Not Segregating and Encrypting Sensitive Data At Rest: Encrypting all data at rest may not make sense, but segregating all personal identifiable information (PII), financial, medical, and any other sensitive or confidential information into a separate, encrypted database is a better attack plan. Even if you are not required to be under PCI or HIPPA or other regulations, limiting exposure to your customer and company confidential information is a best practice. You can add additional protections by tokenizing the information wherever possible. When there is a security breach (probably safe in today’s climate to say “when” not “if” there is a breach), it is really hard to try and explain to your customers why you didn’t encrypt their sensitive data at all times. Given recent headlines, this is now considered entry level security table stakes and a safeguard required by your customers - and no longer a nice to have optional item.
Checklist Only Mentality: In our experience, many auditors have been focused primarily only on checklist compliance until recently - but times are changing and the true test of compliance is moving from a checklist and certification to trying to explain your most recent data breach to your customers and stakeholders. Constantly working towards safeguarding your customers and serving them will likely mean you easily fall within current and future security requirements or can get there quickly. It is much easier to design security into your products now than to be relegated to doing it later because of a misstep and it will do a lot more for customer adoption and retention.
These are just a summary of five common findings – there are certainly many others. The common denominator we find with successful companies is that they are thinking holistically about their customers by automatically building security into their products and are able to scale and expand into new market segments more readily. Building in security as a part of a holistic approach will address areas in business continuity, disaster recovery, resiliency, being able to roll back code, etc.
Under the Hood - Our Security Questions for Technical Due Diligence
In our assessments, we cover each of the areas below - using these questions as guidelines for conversation - not a point-by-point Q&A. These are not a yes/no checklist, we rank our target based on other similarly sized clients and industry averages. Each question receives a ranking from 1-4, with 4 being the highest score and then we graph our findings against similar and competing companies within the market segment.
- Is there a set of approved and published information security policies used by the organization?
- Has an individual who has final responsibility for information security been designated?
- Are security responsibilities clearly defined across teams (i.e., distributed vs completely centralized)?
- Are the organization’s security objectives and goals shared and aligned across the organization?
- Has an ongoing security awareness and training program for all employees been implemented?
- Is a complete inventory of all data assets maintained with owners designated?
- Has a data categorization system been established and classified in terms of legal/regulatory requirements (PCI, HIPAA, SOX, etc.), value, sensitivity, etc.?
- Has an access control policy been established which allows users access only to network and network services required to perform their job duties?
- Are the access rights of all employees and external party users to information and information processing facilities removed upon termination of their employment, contract or agreement?
- Is multi-factor authentication used for access to systems where the confidentiality, integrity or availability of data stored has been deemed critical or essential?
- Is access to source code restricted to only those who require access to perform their job duties?
- Are the development and testing environments separate from the production/operational environment (i.e., they don’t share servers, are on separate network segments, etc.)?
- Are network vulnerability scans run frequently (at least quarterly) and vulnerabilities assessed and addressed based on risk to the business?
- Are application vulnerability scans (penetration tests) run frequently (at least annually or after significant code changes) and vulnerabilities assessed and addressed based on risk to the business?
- Are all data classified as sensitive, confidential or required by law/regulation (i.e., PCI, PHI, PII, etc.) encrypted in transit?
- Is testing of security functionality carried out during development?
- Are rules regarding information security included and documented in code development standards?
- Has an incident response plan been documented and tested at least annually?
- Are encryption controls being used in compliance with all relevant agreements, legislation and regulations? (i.e., data in use, in transit and at rest)
- Do you have a process for ranking and prioritizing security risks?
Subscribe to the AKF Newsletter
Separation of Duties in an Agile Environment
June 26, 2018 | Posted By: James Fritz
For many companies the thought of being audited is never a fun one. Especially when most audits are focused on documentation that is slow to react to an ever-changing environment in the Technology sector. If your company is attempting to utilize Agile methods but you fall under strict regulations for the Payment Card Industry (PCI), Health Insurance Portability and Accountability Act (HIPAA) or Sarbanes-Oxley (SOX), then there is usually a high level of trepidation when it comes to full adoption of Agile into your development. One of the biggest pitfalls that companies run into is in thinking that Separation of Duties (SoD) cannot be achieved in an Agile environment.
What is Separation of Duties?
In short, SoD is ensuring that no one person holds all the keys to enact any change. If a developer can create a product and push it into production with no checks, then this is a violation of SoD. The two basic premises this is designed to create is the elimination of fraud and the detection of errors. So, by having checks and balances along the way your company is more secure against fraud and error that would naturally occur with the introduction of human intervention.
This separation is key for any of the above-mentioned standards, PCI, HIPAA or SOX. An excerpt out of the PCI Data Security Standards states,
“In environments where one individual performs multiple roles (for example application development and implementing updates to production systems), duties should be assigned such that no one individual has end-to-end control of a process without an independent checkpoint.”
All three of the regulations share similar verbiage. No one person can have control from the beginning to the very end. But that is the inherent beauty of a fully adopted Agile system. No one person has complete control. The system relies heavily upon automation.
If you look at a normal Agile Development process (see graphic below) there are still clear timelines and interjections of human input, on top of the vast automated input provided. This creates a system that brings in a committee of personnel to achieve certain goals every sprint. When automation is laid on top of the human based work then another layer of checks and balances is established. And this automation is not just a random compiler that was pulled off the internet. It has agreed upon criteria and testing mechanisms that have been refined over time by a team that documents what is being tested against. So if an auditor were to ask, “How do you check against X?” then you would have a clear answer from the documentation that “X” is checked and logged at this stage in the process.
If your developers are utilizing proper version control and your automated systems are documented then you would have a higher chance of catching any changes, whether purposeful or accidentally, than you would in another life cycle development model. If left purely up to humans, then the ability to get distracted and lose focus would end up creating more errors than a more highly automated system would. Agile practices can help reduce human error.
Additionally, if you are looking to capture any sort of fraud then you would be able to implement more monitoring on your privileged developers specifically. Between this monitoring and the automated testing, it should be easily caught if one of your developers goes outside of a scope that they are supposed to be working in, thus protecting any sensitive data that would be required under PCI, HIPAA or SOX regulations. Not only will this automation and monitoring help stop fraud internally, it also can help detect actors on the outside attempting to gain access to your sensitive data.
Do I actually need Separation of Duties?
Yes. And if utilizing an Agile framework you already have that separation. Everything about creating an Agile environment lends itself towards highly auditable and loggable activity. This same activity is what is required for SoD. Checks and balances are achieved when you create, document and continually refine the process of how your company delivers viable product sprint after sprint. Auditors are quick to say that Agile doesn’t support the necessary separation, but usually that is because there isn’t a single person that they can put their finger on that does a certain activity. Instead they have a refined and documented product, both heavily monitored and logged, that is the independent checkpoint they require to ensure that no individual has complete end-to-end control.
If you have any further questions on how your Agile environment follows Separation of Duties, feel free to contact AKF.
Subscribe to the AKF Newsletter
1 2 >