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?
Separation of Duties 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
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.
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.
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.
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:
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.
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
< 1 2