The systems development life cycle (SDLC) is a process any IT team member or software developer will be familiar with.
When most people hear about the SDLC, they think it is strictly about developing programs, such as websites and applications. It is much more than writing code; it’s about change management in your systems.
Every company works differently, so SDLC processes will change from company to company. For companies with an Employee Stock Ownership Program (ESOP), it is important to make sure your SDLC is well-planned, complete, and documented to protect your employee-owners and customers.
Guide Star can help establish an enterprise architecture by creating documentation with the right mix of agility and oversight. As the wizards behind the curtain, our experts can help you execute an SDLC to suit your company and employees.
When you’re going through the systems development cycle, there are cybersecurity best practices you should follow to keep in compliance with the Department of Labor’s (DOL) guidelines for ESOPs.
Systems Development: Internal and External
The systems development life cycle has some parts of it that are particular to coding. The SDLC is about managing the changes throughout the lifespan of a system. The most important aspects of the SDLC are the processes.
How you plan to do something or how you have been doing something needs to be documented for cybersecurity purposes.
You will need to focus on both the internal and external elements of systems development.
Internal Systems Development
Developing your systems internally can appear to be straightforward on the surface. However, it is important to keep your best practices and code management top of mind.
Best Practices and Frameworks of SDLC
There are many frameworks you can pull best practices from. Agile and Waterfall are two of the more popular development methodologies. Depending on how your IT department manages change, any one of them will help them stay compliant.
Even if you create your own methodology, there are a few steps to the process that every methodology has in common:
- Your changes must be documented, planned, approved, and tested.
- After the changes are tested, they are promoted to the appropriate environment.
- After promotion, the changes need to be tested again.
- The changes are deployed to the production environment.
- Once in the production environment, they are tested a third time.
- Based on testing in the production environment, the change is either accepted or rolled back.
There will be small differences in each step depending on your chosen framework.
Historically, developers have focused testing on functional use cases, like “If you click this button, text will generate”. Only focusing on functional use cases leaves your programs vulnerable. Function needs to be a component of your requirements, but security needs to be architected the right way.
While testing the function is important, you also need to understand and learn how to test for security, what you’re testing, and what your standards are.
As you’re testing, you need to document every step. This proves you have completed the testing and what steps you took to test.
Throughout each phase of development, you are testing against security standards, so it needs to be documented to comply with both your chosen cybersecurity framework and the DOL’s guidelines for ESOPs.
Taking the time to plan, approve, test, promote, and document is an example of secure coding and migration practices.
Code Management During Systems Development
In March 2020, software developer SolarWinds sent out a software update for their Orion software. Instead of a regular update, more than 18,000 SolarWinds customers received malware.
Federal agencies, like the Departments of Homeland Security, State, Commerce, and Treasury were affected by this malicious update. The businesses and agencies using Orion were not the only ones impacted, even their own customers and partners were at risk for a data breach.
How did this happen?
Hackers were able to gain access to SolarWinds’s systems and not only insert their bad code but also tested it months before the update went live.
Following proper code management procedures in the SDLC, like documenting your changes and peer reviewing code, would have prevented the bad code from going live.
Secure Code Repositories
Supply chain attacks are scary because they create an opportunity for hackers to exploit one system and then leverage it against multiple targets. To keep safe, remember your production environment is not the only environment that needs to be monitored for security.
Where your code is housed and how your developers access it is just as important as not being able to break your app once it is published.
To make sure your code is secure, your developers need to store their code in a repository. There are many secure code repositories available to protect your code during and after development, such as GitHub, Bitbucket, and Microsoft’s Azure DevOps. 
Checks and Balances with Peer Reviews
Storing your code securely is only part of keeping it safe. You also need to manage the different types of access. There are many layers of access in a code repository ranging from editing code to promoting it to the production environment.
Your IT team’s systems development cycle should include a system of checks and balances. One developer should not be able to promote their own code into the production environment.
A common secure coding framework developers use is OWASP. OWASP provides resources for developers to learn about safe and unsafe coding practices, including recommending a peer review.
As a part of your testing component, include a peer review process for a fresh perspective on any security issues your developers might have missed.
During the peer review, your peer reviewer should follow the OWASP guidelines to ensure none of their Top 10 security risks are in the code. Before you promote any code, it needs to be peer reviewed to make sure there are not any vulnerabilities or open ports for hackers.
An important function of your code repository is logging. In the logs, tools can scan the code to check for any unusual activity, like commits that weren’t expected or code that doesn’t look right. These are cyber hygiene tools that run against the code in your repository.
Using processes like peer review and permission levels, and using tools like logs and scanning can make it harder for any malicious code to sneak in.
The checks and balances ensure more than one person checks their coworkers’ work. Instead of a single layer of security, there are multiple hurdles a hacker would need to clear to sneak bad code into a production environment.
Getting your developers trained on secure coding practices and getting your IT team—who are introducing the changes—on secure deployment methodology are vital to your cybersecurity success. The Systems Development Life Cycle policy and procedure will not be worth it if your IT team doesn’t know how to enforce the standards you are creating.
External System Development
Every company uses a system developed and maintained by an external vendor. While you don’t have any say in your vendor’s SDLC, there are steps you can take to keep your employees and your other systems safe.
Your enterprise architecture (EA) team comes into play when talking about external system development. A part of your EA team’s standards should be about external vendors and their secure coding practices and SDLC best practices.
If the vendor follows any of the previously outlined secure practices and documentation providing it, then they will most likely pass your review. It is important to look for any security certifications—like SOC 2—to prove they are following cybersecurity best practices.
Be Notified of System Updates or Changes
External vendors will need to deploy changes to their systems, and you will need to be aware of when it is happening.
For some systems, you will have the ability to determine when you want the change to go live for your users. Some factors can drive change, and sometimes, those changes can create new risks for your systems.
When a vendor announces a major release, you need to evaluate the change. Ask yourself these questions.
- What is being affected by the change?
- Does your company want to enable the new changes?
- Are there any security risks involved?
- Does this new release trigger an EA review?
A Change Advisory Board (CAB) can help manage these changes.
Establishing a Change Advisory Board
Your CAB relates to your enterprise architecture team as it determines whether the changes are acceptable. If the change is massive, your EA team might need to reevaluate the system to check if it is still compliant with your standards.
Changes can range from minor updates like patches, a new version release, or even the acquisition of the company. Your CAB will know which systems are changing and why they are being changed.
Security needs to be a component of your Change Advisory Board, so they can call out the risks of accepting that change. They can also advise on adoption plans for changes and timelines for the change to go live. The overall purpose of the CAB is to understand the changes going on within your systems.
If a change were to be accepted, your CAB ensures that new versions of the tools and systems you’re using align to your SDLC standards.
How to Begin the Systems Development Life Cycle
As an executive, part of managing changes is making sure those changes are happening in the right environment, the right people are making them, and all changes are well-documented. Whether the changes occur internally or externally, a well-planned systems development life cycle will keep your team and company on track.
Your board needs to be aware of and approve your policies and procedures to include the steps to secure development. You can eliminate a lot of security risk simply by documenting every change that is made.
Documented changes provide your development team with a before-and-after view. You have documented changes and you have logs. If your documented changes correlated to your logs, then nothing unusual is happening in your systems.
Guide Star can give guidance on how to implement a Change Advisory Board and establish the checks and balances to keep your company and employees safe.
If assembling a sound enterprise architecture is what you need, Guide Star can help there, too.