An insight into my role as a SISO - part three

In part one I talked about what a SISO is, and explained about giving advice, vulnerability management, validating security reports, penetration tests, and security questionnaires.  For part two I discussed incident response and investigations.  In this final part I'm going to talk about my involvement in the secure software development lifecycle. working with customers, and staying up to date and relevant in information security.

Feature security reviews

Part of the secure software development lifecycle involves considering security during the software design process.  Research has shown that if security checks / considerations are left to the end of a project, they are often missed or not tested for.  To then fix any issues costs more than having implemented the relevant security features in the first place!  Instead, it's better to ensure security is part of the specification for the system, and to build it in as the software is developed.

To help with this, any new features that we look to develop go through security and compliance reviews.  During this stage I have the opportunity to indicate what needs to be done so the feature can be implemented safely and securely.  Although I'm a developer myself, and have been since I was a teenager, I don't generally tell our development teams how to write the code for the security requirements - I give them a list of required outcomes and then they implement that in a way that fits the application and the programming language they're using.

In order for me to identify the security requirements, the team provides details of what they're trying to achieve, what data they'll be using (e.g. data from a third party API [1] or entered by a person), and how they plan to implement the functionality. Process and data flow diagrams are particularly useful to me as they provide a quick to understand summary.  Once I've read about the design, and any supporting documentation, I'm able to explain what I need to see added from a security perspective.  Often these are:

• Connections to third party APIs must be encrypted and authenticated (although a lack of authentication is at the third party's risk, and may not be a reason to abort)
• If we're hosting the API, connections must be encrypted and authenticated
• API access must be rate limited (either in to us or out to a third party) to prevent performance issues
• Data must be encrypted at rest (on storage) and in transit (being sent between systems)
• Data must be sanitised before use

But there are also a number of more specific requirements, depending on the feature.  Our existing policies also apply requirements, some that I've reinforced above, that includes "no known vulnerable third party components should be used".

Once developed, I check in with the team to make sure the security requirements were met.  Sometimes things have been missed, so the feature either goes back to the development stage or has to be added retrospectively (what we were trying to avoid!).

Maintaining good relationships with customers

While I'm sure we and our customers both want to have a good relationship, some customers require more contact such as quarterly check in calls.  These check ins can be particularly useful when the customer is keen for a strong two-way relationship, when the customer shares threat intelligence or provides advanced warnings of any changes they'll be making that we'll have to react to.

Following an audit, our relationship with one customer meant they looked at the results and realised that we weren't reflected in the findings.  The customer knew how we worked and the report they had been given wasn't a true reflection on us at all.  This was good, because it meant the customer wasn't immediately panicking, but we still had to provide the evidence to refute anything highlighted as "an issue".

Customer meetings

I've mentioned check ins already, but customer meetings can also happen following incidents or during contract negotiation / renewal.  As part of security questionnaires I've ended up on a number of calls where the customer has asked for more details, or to be shown evidence.  I've also ended up debating contract terms to make sure what's being requested is understood and feasible for our environment.  Sometimes this has meant deleting portions from the contract, as the clause doesn't apply (the contract was generic).

Are you impacted by...

Our more security conscious customers, often those with security teams themselves, will sometimes email asking if we're impacted by a particular vulnerability that's been in the news or been in threat intelligence summaries.  One example is the Screen Connect vulnerability from February / March 2024: CVE-2024-1709.  Customers that ask if we're impacted often want a response the same day, which is often possible given the vulnerability management tools we use and the Software Bill Of Materials (SBOM) [2] that we have for what we've developed.

In case you're wondering, no, we were not vulnerable to the Screen Connect vulnerability.

Staying up to date - CPE / CPD

Continuing Professional Education (CPE) or Continuing Professional Development (CPD) are essentially the same thing, and they're crucial to keeping up to date and relevant in information security (and IT generally).  As security professionals, we work in a fast changing field so it's important to make sure we understand current threats, attacks, and the technologies we can use to keep our organisations safe.

Generally, I schedule time once per week where I look at security news.  I'll use a variety of sites, including forums such as Reddit, to get an understanding of what's changing in terms of defensive and offensive (attack) tooling, any new or increased threats, and anything else it might be helpful to know.  I then take that information and work out how it applies to my workplace.  Sometimes what I've found doesn't apply - perhaps we're not using the affected product - but other times I've had to go away and make further checks within our systems.

I also wrote some CPE / CPD tips in a previous blog post if you wanted some suggestions on how to stay up to date - you don't need to spend a lot of money 😊.

There's still more

I'm pretty certain that I've not listed everything here, as my role means that no two days are the same.  I can plan my day as much as I like, but I may have to drop everything at a moment's notice to react to some event or threat to the business.  This keeps the variety in my role, certainly, but can sometimes be frustrating - I've had work delayed by months as a result.  Hopefully this series gives you a bit of an insight into what I do, and how my role helps the business.

Banner image: "Computer Programmer - colour", from OpenClipart.org, by j4p4n.

[1] API stands for Application Programming Interface and is a way for applications (be they full desktop applications, a smartphone app, or a web application) to exchange data.

[2] A Software Bill Of Materials (SBOM) is a list of components used in an application.  Think of it like a parts list for how to build a piece of furniture or a car.  We can review the SBOM to see if a vulnerable component is included in our software.