lance.to

Originally written October 9, 2020

As software engineers*, particularly when working at our employer, we're often writing software to be used by other people. In most cases it's our company's customers, and if we're doing it right we're writing focused, well thought out tools and apps that serve to solve our customers' business problems. This is purposefully vague, but suffice it to say the point of why we're getting paid money to write lines of modular, logically organized lines of camel case words and syntax is because someone we probably don't know personally (the customer) is paying us to do it. There are likely other people at your company like business analysts, marketers, and even sales reps/engineers who's responsibility it is to do market research, talk to and gather feedback from prospects and customers, and ultimately help drive the roadmap for what you end up writing. Rarely though do we get the opportunity to use the software either because it's not useful to us or we're not responsible for the activities done in our organization that the software helps with. We also don't usually get opportunities to hear things from the horse's mouth (the customer) about how we should write something based on their current workflow or why.

Unfun problems

Vendor & Risk Management

At risk3sixty our R&D efforts with Phalanx are focused on solving security and compliance problems that we've struggled with ourselves. As a manager on the engineering team, I'm responsible for performing vendor management reviews for a few vendors we use in our software workflows (object storage, CI/CD, PaaS). Where do I schedule a recurring calendar task to perform these quarterly reviews? I guess I'll just throw a quarterly recurring invite on my personal calendar (but wait what happens when I'm on vacation during the next scheduled review date...). When performing a review, I've identified a couple risks that I wanted to document and track through to either remediation or simply document risk acceptance depending on its severity and potential action items to remediate. Where do I document the risk? Let me email my boss the risk(s) and have her propagate upwards to have someone with access populate in the master organizational risk register spreadsheet. Oh wait, we actually added a SOC 2 control during design of controls that was added specifically to mitigate a risk posed by one I just identified for a vendor. I want to document that this risk is associated with that control, should I tell my boss to add a note in the risk register which control this risk is mitigated by, or do we have our list of SOC 2 controls in a spreadsheet or somewhere and link the risk there?

All of the italicized bits above are real questions or concerns that not only we were faced with, but also are our customers when effectively managing organizational risk and designing a program to manage said risk across the board. I'm able to actually use the software we're writing to solve our customers' problems to solve my own now. With more and more companies not doing business with vendors who are not ISO 27001 certified, SOC 2 compliant, or other niche industry-standard frameworks, being able to effectively and efficiently perform the mentioned actions above is paramount in keeping things organized and ensuring future audits are run smoothly and quickly later on.

Audit Spaghetti

When performing a SOC 2 or ISO 27001 audit, obviously a huge chunk of the time is scheduling walkthroughs to help guide you to organize the right people together to obtain evidence that you either are or are not implementing the necessary controls required to be compliant with the framework. Anyone who has gone through an audit like this from the customer side is aware of this walkthrough and evidence collection process (which depending on the firm might or might not happen by sending files across emails [facepalm]). What you don't usually see are the number of spreadsheets, word docs, internal emails, management review (inside the same spreadsheets and word docs), and ultimately sharepoint spaghetti that takes place on the backend between evidence collection and report generation to successfully execute a full engagement. This is incredibly inefficient and we've aimed at streamlining the audit process for both the customer and auditor to provide the most meaningful information and simplest steps to perform the audit in an easy and efficient manner. Now when I have to provide evidence to our auditor for something from the R&D side or any of our consultants are performing audits, we utilize all the tools we build in Phalanx to accomplish the tasks at hand.

Eating our own dog food

For our customers where it's import to remain compliant with the frameworks their business and/or industry requires, it behooves them to have and maintain processes in place to ensure you're regularly doing user access reviews, vendor reviews, maintaining and acting on an up-to-date risk register, keeping an up to date asset inventory, and many more. For me, I'm able to maintain a level of sanity for myself with the added benefit of continuing to build quality software all while performing my compliance duties for risk3sixty.

In Phalanx we have purpose-built modules and functionality to help you organize and maintain your entire security and compliance efforts in a single pane of glass:

1. Assessments – Perform your own internal audits to allow for auditing business units, departments, etc. for compliance with organizational controls and/or identify risk.
2. Compliance Calendar – Create recurring tasks and assign to stakeholders and those responsible for performing compliance actions.
3. Vendor Management – Document all of the third party vendors you do business with, perform regularly scheduled vendor reviews (integrate with compliance calendar), send out questionnaires to vendors to answer security questions, quantify risk associated to business, etc.
4. Risk Register – Document and organize organizational risks you'd like to track and document through to remediation. Link risks to vendors (or specific reviews), calendar events, audit controls, etc.
5. Inventories – Build a generic inventory of “things” (think building a custom BIA, asset inventory, organizational vulnerability list, etc.) We maintain a list of assets and a BIA among other things and link to assessment controls, risks in registers, owners, etc. in these inventories.

Use it, use it , use it

In closing, I'm here to say that as an engineer the best tool you have at your fingertips to help build useful software is to use it yourself. Not everyone is empowered or is able to do this, but I think it helps tremendously in helping your customers remain happy in the long term.

* I've seen some heated debates as to whether software developers deserve the title “engineer”. The most common argument it appears to not give them the title is most engineering practices require some industry standard credential or certification that gives them the credibility and in some cases legal ability to practice that particular classification of engineering. There doesn't exist the same thing in software, but I argue most software developers have not only the aptitude, but possess the skills necessary to be outstanding engineers, so I like to continue to think of myself as an engineer.