AKF Partners

Abbott, Keeven & Fisher Partners Partners in Technology

Growth Blog

Scalability and Technology Consulting Advice for SaaS and Technology Companies

The AKF Partners Security Insights Cube

February 13, 2018  |  Posted By: Marty Abbott

Necessary But Insufficient Security Reviews

From a security perspective, tech product companies far too often focus solely on various ISO and/or NIST audits to help inform their view of how they manage risk within their company and their products.  The problem with the standards that exist today is that none of them tread deeply enough into the waters of detection and prevention of malicious activities within products.  Instead, they focus more on the processes of response, identification, notification, employee access, etc.

While these activities (and audits) are necessary, they are insufficient to ensure that we properly manage risk (and prevent malicious activities) in our products.  As we’ve written previously, erecting barriers and hiding behind big walls may make you feel better and help you sleep at night – but it’s not going to keep the bad guys from scaling your walls and taking your stuff.

The Online World is Getting Scarier
Consider the following secular trends for online products:
• A continuing mix-shift of commerce from retail to online.  Within the US today, excluding certain goods, this number stands at a meager 9% of total commerce in 2017 up from 1% in 2002.  If one excludes extremely high dollar items (vehicles, etc) the percentage of sales is significantly higher.  Growing at a slightly higher than linear rate since 2002, this number should easily double within the next 7 years.  From the perspective of a malicious hacker, this is a growth in opportunity.

• Developing and established nations outside of N. America and Western Europe continue to invest heavily in STEM-based education.

• Overall employment in many of these countries is comparatively low outside of what Western Nations provide through off-shore contracting opportunities.  Combined with recent nationalistic trends and a desire to “keep jobs at home” or not “offshore jobs” there is a strong possibility that demand for offshore agencies will decrease over time.

• Some nations within the set of nations spending heavily on STEM education, have created cyber-institutes promoting cyber and security related warfare capabilities.

• A smaller set of the nations described above have heavily promoted state sponsored cyber warfare initiatives, setting these teams (e.g. the PRNK’s Unit 180) against corporate infrastructure within the United States. 

• The barrier to entry for malicious actors to be effective in attacking corporate assets has declined.  Hacker communities commonly share exploits and malware, and certain nation-states (e.g. Russia and N. Korea) have contributed to hacking toolsets, thereby decreasing the barrier to entry for a malicious actor and resultingly increasing the supply of said malicious actors.

• Extradition from other countries for crimes committed, especially those with which the US is not allied, is difficult to impossible.  View this as a low perceived cost of committing a crime.  If you cannot be prosecuted, there is no to low perceived cost of committing the crime.

• Crypto-currency (e.g. Bitcoin) provide a near untraceable means of selling stolen data, or holding systems for ransom.

The resulting forces of these meta or secular trends are clear: 

1) The value of being a malicious actor has increased as the supply (in terms of sales/value) continues to increase.  View this economically as an increasing opportunity for crime.

2) The barrier to entry to become a malicious actor is decreasing.

3) The cost in terms of prosecution, if performed outside the US is low to zero.

These points combine to make one clear outcome:  Cybercrime and cyberterrorism (fraud, malicious use, etc) will rise as a percentage of revenue transacted online.

To help combat this rising malicious activity, we need new models and approaches to help us think about how to Identify and Prevent bad actors from doing horrible things.

Enter the AKF Security Insights Cube.

If It Isn’t Real Time It Is Worthless

The AKF Partners Security Insights Cube is predicated on the notion that all the data it addresses is accessible in near-real-time.  This alone is a considerable barrier for many companies.  Identifying fraudulent activity after credit cards are processed, for instance, is simply too late.  We want to know that bad people are entering our neighborhood and at our door – not that they stole something from our house yesterday.

The lower left corner of the cube is the starting point for any solution – the point at which you are flying blind and have no real time data.  Again – getting data from 15 minutes ago or 24 hours ago is as useless in driving a product as it is in driving a car or flying a plane; you simply have no idea what is going on.

X Axis

The X axis of the cube evaluates the breadth of data available to an organization in real time.  The far left is “zero real time data”.  Progressing to the right of the axes are increasingly valuable risk related data points from real time key performance indicators like logins, add-to-carts, check-outs, auth activity (and failures), searches, etc.  Moving further right, we may keep all session data such that we can interrogate and perform behavioral analysis and pattern matching.  The far right of the axis is the point at which we keep absolutely everything, increasing the optionality of how we may interrogate the data for risk management and malicious activity prevention purposes.

Y Axis

The Y axis of the cube evaluates the activities performed upon the X axis data by an organization.  Clearly here the X axis sets an upper bound on what’s possible on the Y axis.  For instance, it would be hard to understand “Who, What or How” something happened if we didn’t first store session data to be analyzed.  From a GDPR perspective, PII can be anonymized if necessary in session information.  As with most analytics oriented system, maturity progresses from doing nothing, to “reporting” capabilities that illuminate “what is happening” (typically employing performance indicators), to answering “Who, Why and How” to finally predicting what will happen and preventing malicious activities in real time.

Z Axis

The Z axis of the cube deals simply with the depth, or duration, that data is kept.  We rarely suggest that data be kept forever, but there is great value in ensuring that past patterns can be analyzed to create behavior models for scoring risk and blocking activities.  A handful of years is typically appropriate for most commerce solutions, slightly more data for fintech solutions.

AKF Partners performs security reviews of technology products.  Our approach evaluates security among several dimensions and includes components of NIST and ISO standards, but is tailored to the needs of online product companies. 

Subscribe to the AKF Newsletter


Technical Due Diligence Best Practices

January 23, 2018  |  Posted By: Marty Abbott

Technical due diligence of products is about more than the solution architecture and the technologies employed.  Performing diligence correctly requires that companies evaluate the solution against the investment thesis, and evaluate the performance and relationship of the engineering and product management teams.  Here we present the best practices for technology due diligence in the format of things to do, and things not to do:

The Dos

1. Understand the Investment/Acquisition Thesis

One cannot perform any type of diligence without understanding the investment/acquisition thesis and equally as important, the desired outcomes.  Diligence is meant to not only uncover “what is” or “what exists”, but also identify the obstacles to achieve “what may or can be”.  The thesis becomes the standard by which the diligence is performed.

2. Evaluate the Team against the Desired Outcomes

The technology product landscape is littered with the carcasses of great ideas run into the ground with the wrong leadership or the wrong team.  Disagree?  We ask you to consider the Facebook and Friendster battle.  We often joke that the robot apocalypse hasn’t happened yet, and technology isn’t building itself.  Great teams are the reasons solutions succeed and substandard teams behind those solutions that fail technically.  Make sure your diligence is identifying whether you are getting the right team along with the product/company you acquire.

3. Understand the Tech/Product Relationship

Product Management teams are the engines of products, and engineering teams are the transmission.  Evaluating these teams in isolation is a mistake – as regardless of the PDLC (product development lifecycle) these teams must have an effective working relationship to build great products.  Make sure your diligence encompasses an evaluation of how these teams work together and the lifecycle they use to maximize product value and minimize time to market.

4. Evaluate the Security Posture

Cyber-crime and fraud is going to increase at a rate higher than the adoption of online solutions pursuant to a number of secular forces that we will enumerate in a future post.  As such, it is in your best interest as an investor to understand the degree to which the company is focused on increasing the perceived cost of malicious activity and decreasing the perceived value of said malicious activity.  Ensure that your diligence includes evaluating the security focus, spending, approach and mindset of the target company.  This need not be a separate diligence for small investments – just ensure that you are comfortable with the spend, attention and approach.

The Don’ts

1. Don’t Waste Too Much Time (or money) on Code Reviews
The one thing I know from years of running engineering teams is that anytime an engineer reviews code for the first time she is going to say, “This code is crap and needs to be rewritten.”  Code reviews are great to find potential defects and to ensure that code conforms to the standards set forth by the company.  But you are unlikely to have the time or resources to review everything.  The company is also unlikely to give you unfettered access to all of their code (Google “Sybase Microsoft SQLServer” for reasons why).  That leaves you at the whims of the company to cherry-pick what you review, which in turn means you aren’t getting a good representative sample. 
Further, your standards likely differ from those of the target company.  As such, a review of the software is simply going to indicate that you have different standards. 
Lastly, we’ve seen great architecture and terrible code succeed whereas terrible architecture and great code rarely is successful.  You may find small code reviews enlightening, but we urge you to spend a majority of your time on the architecture, people and process of the acquisition or investment.

2. Don’t Start a Fight
Far too often technology diligence sessions start in discussion and end in a fight.  The people performing the diligence start asking questions in a way that may seem judgmental to the target company.  Then the investing/acquiring team shifts from questions to absolute statements that can only be taken as judgmental.  There’s simply no room for this.  Diligence is clinical – not personal.  It’s not a place to prove who is smarter than whom.  This dynamic is one of the many reasons it is often a good idea to have a third party perform your diligence:  The target company is less likely to feel threatened by the acquiring product team, and the third party is oftentimes more experienced with establishing a non-threatening environment.

3. Don’t Be Religious
In a services oriented world, it really doesn’t matter what code or what data persistence platform comprises a service you may be calling.  Assuming that you are acquiring a solution and its engineers, you need not worry about supporting the solution with your existing skillsets.  Debates around technology implementations too often come from a place of what one knows (“I know Java, Java rocks, and everything else is substandard”) than what one can prove.  There are certainly exceptions, like aging and unsupported technology – but stay focused on the architecture of a solution, not the technology that implements that architecture.

4. Don’t Do Diligence Remotely
As we’ve indicated before, diligence is as much about teams as it is the technology itself.  Performing diligence remotely without face to face interaction makes it difficult to identify certain cues that might otherwise be indicators that you should dig more deeply into a certain space or set of questions.  Examples are a CTO giving an authoritative answer to a certain question while members her team roll their eyes or slightly shake or bow their heads.

You may also want to read about the necessary components of technical due diligence in our article on optimizing technical diligence.

AKF Partners performs diligence on behalf of a number of venture capital and private equity firms as well as on behalf of strategic acquirers.  Whether for a third party view, or because your team has too much on their plate, we can help.  Read more about our technical due diligence services here

Subscribe to the AKF Newsletter