AKF Partners

Technology Consulting Partners in Technology Success

Growth Blog

Scalability and Technology Consulting Advice for SaaS and Technology Companies

The AKF Difference

December 4, 2018  |  Posted By: Marty Abbott

akf difference

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 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.

Most 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 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

Contact Us

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.”

-Benjamin Franklin

...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.

Data Breach

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.

Similarity
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.

Interconnections
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.

Users
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. 

Motive
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.


RELATED CONTENT

Subscribe to the AKF Newsletter

Contact Us

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. 

RELATED CONTENT

Open Source Software as a malware on ramp

5 Focuses for a Better Security Culture

3 Practices Your Security Program Needs

Security Considerations for Technical Due Diligence

Subscribe to the AKF Newsletter

Contact Us

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.

RELATED CONTENT


5 Focuses for a Better Security Culture

3 Practices Your Security Program Needs

Security Considerations for Technical Due Diligence

 

Subscribe to the AKF Newsletter

Contact Us

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:

AKF Focuses for 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.

Business vs Security

-Training
        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.

-The Audience
        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.

Security Collaboration

-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.


Related Articles:

Subscribe to the AKF Newsletter

Contact Us

Managing Risk

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.

Handling Risk

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.

AKF Risk Model

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.


Related Articles:

Subscribe to the AKF Newsletter

Contact Us

Tech Due Diligence - 5 Common Security Mistakes

June 28, 2018  |  Posted By: Pete Ferguson

AKF Partners Growth Blog Scalability Cube - Credit Shutterstock 413190667


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.


AKF Partners Scalability Rule 15 Firewalls Everywhere


  • 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.

Conclusions
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.

  1. Is there a set of approved and published information security policies used by the organization?
  2. Has an individual who has final responsibility for information security been designated?
  3. Are security responsibilities clearly defined across teams (i.e., distributed vs completely centralized)?
  4. Are the organization’s security objectives and goals shared and aligned across the organization?
  5. Has an ongoing security awareness and training program for all employees been implemented?
  6. Is a complete inventory of all data assets maintained with owners designated?
  7. Has a data categorization system been established and classified in terms of legal/regulatory requirements (PCI, HIPAA, SOX, etc.), value, sensitivity, etc.?
  8. Has an access control policy been established which allows users access only to network and network services required to perform their job duties?
  9. 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?
  10. Is multi-factor authentication used for access to systems where the confidentiality, integrity or availability of data stored has been deemed critical or essential?
  11. Is access to source code restricted to only those who require access to perform their job duties?
  12. 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.)?
  13. Are network vulnerability scans run frequently (at least quarterly) and vulnerabilities assessed and addressed based on risk to the business?
  14. 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?
  15. Are all data classified as sensitive, confidential or required by law/regulation (i.e., PCI, PHI, PII, etc.) encrypted in transit?
  16. Is testing of security functionality carried out during development?
  17. Are rules regarding information security included and documented in code development standards?
  18. Has an incident response plan been documented and tested at least annually?
  19. Are encryption controls being used in compliance with all relevant agreements, legislation and regulations? (i.e., data in use, in transit and at rest)
  20. Do you have a process for ranking and prioritizing security risks?

Related Articles:

Subscribe to the AKF Newsletter

Contact Us

Separation of Duties in an Agile Environment

June 26, 2018  |  Posted By: James Fritz

Separation of Duties in an Agile Environment - AKF Partners Technical Due Diligence

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.

Separation of Duties

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.


Agile Development

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.


Related Articles:

Subscribe to the AKF Newsletter

Contact Us

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

Contact Us

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.  Ensure that your diligence properly evaluates the risk of the target solution.

5. Prepare Yourself and the Target

Any diligence will go better if you give the acquisition/investment target an opportunity to prepare documents.  Requesting materials in advance allows the investment target an opportunity to prepare for a deep discussion and ensures that you can familiarize yourself with the product architecture and product development processes ahead of time.  Check out our article on due diligence checklists which includes a list of items to request in advance.

6. Be Dynamic and Probe Constantly

While a thorough list of items to discuss is important, it is equally important to abide by the “2 ears and one mouth” rule:  Spend more time listening than talking.  Look for subtle clues as to the target’s comfort with particular answers.  Are there things with which they are uncomfortable?  Are they stressing certain words for a reason?  Don’t accept an answer at face value, dig into the answer to find the information that supports a claim.

7. Evaluate Debt

Part of the investment in your target could well be an ongoing premium payment against past technical debt.  Ensure that you properly evaluate what debt the company has acquired, and how they are paying the interest and premium payments against that debt.


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

RELATED CONTENT

Subscribe to the AKF Newsletter

Contact Us