During this first week’s reading assignment, I learned there are many different methods for developing a software development lifecycle (SDLC). For example, for most SDLC’s, the basic response steps include planning, analysis, design, implementation and maintenance. However some organizations, such as Microsoft, will add additional steps to the process or define a step differently.
MSFT’s Software Development Lifecycle includes training, requirements, design, implementation, verification, release and response. Each member of the development team must receive training in security basics and trends in security. This is to help make the team start their SDL with security in mind. With this additional step, it can help prevent the company from committing security errors because they weren’t looking at their project with security as a focus. Even with this extra step, the process outlined by MSFT can be used in many frameworks. They can use Agile, CASE, DevOps or DevSecOps when trying to implement their process.
I feel adding a step such as training is a must for most organizations. Applications must be developed with security as the top priority. If the SDLC process doesn’t have the correct security measures in place, the organization could end up being the next SolarWinds.
SDLC IN THE NEWS
SDLC has been in the news a lot lately due to the SolarWinds supply chain attack which occurred last month. During the SolarWinds attack, the intruders were able to leverage the SDLC of SolarWinds and move laterally within the organization. The attackers made their code look authentic and were able to inject it into the ORION platform. The SDLC process from SolarWinds didn’t find the intruders code in the DLL file. This allowed the ORION platform to be updated with this file included. Customers would visit the SolarWinds site and download the new file. The admins then updated their ORION software. The new software would download the DLL, allowing intruders to potentially invade other organizations. All of the traffic to and from the ORION application looked authentic. The attackers did a very good job of making everything look legitimate. Because of this major issue, the SDLC process is under heavy scrutiny within most large application development companies.
https://www.guide-rails.io/resources/the-solarwinds-breach-and-securing-the-sdlc
https://securityboulevard.com/2020/12/solarwinds-sunbrust-backdoor-investigation-using-shiftlefts-code-property-graph/
For more information about the SolarWinds attack, read this blog by FireEye: https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html
SolarWinds is an international IT management software provider. There is an infected update program on its Orion software update server, which has caused the network of many US companies and government units to be infected. The related incident triggered by the supply chain attack was the hacked announcement issued by FireEye on December 8, which may have leaked a series of network security testing tools for evaluation. On December 13, FireEye issued an announcement confirming that a backdoor caused the SolarWinds software update package’s intrusion.
Since the attacker obtains a regular manufacturer’s certificate and uses it to sign itself, all organizations that trust the certificate are at risk of being compromised. Especially in cloud services, the attacker may use this forged token to bypass and log in to other companies’ environment to complete a wider range of intrusions. Since the user has trusted the SolarWinds, the attacker can forge the SolarWinds token, deceive and bypass the protection, establish a high-privileged account in the target network environment, wait for the opportunity to complete the attack target.
Customers who use SolarWinds products should promptly investigate abnormal resource access records in the system, determine the source of access, and check whether they have fully trusted the SolarWinds certificate. If border protection equipment has been deployed, threat intelligence products should be linked to obtain IOCs to intercept potential attacks quickly.
From this week’s reading assignment, Chapter 3 of the CISA Manual, I learned the key processes that organizations implement when creating or changing application systems. I also learned about DevOps, which refers to the integration of development and operations processes to eliminate conflicts and barriers. DevOps integration can create a huge amount of benefits, but at the same time, it can create new data risk. The chapter explains that the decision to adopt DevOps should be made based on factors such as an organization’s climate, risk tolerance, culture, and objectives. Since DevOps changes the organization’s control environment and accepted level of risk, an IT auditor should ensure that there is proper separation of duties.
Another important takeaway that I learned from this week’s lecture was about the SDLC. I learned that SDLC stands for System Development Life Cycle or SDLC. SDLC is a traditional methodology used to develop, maintain and replace information systems. The cycle consists of 5 basic phases which are: Planning, Analysis, Design, Implementation, and Maintenance. Another important take away was that not all organizations or business have the same phases as discussed above. For example, Microsoft has more phases that include training and response phases into their system development life cycle.
I think you picked 2 of the biggest and most complex issues our there today. DevOps and the challenges and SDLC optimization. DevOps is a different way for many organizations to look at software delivery – as you noted, it can also create conundrums for auditors! In a DevOps world the Developers can have access to Production environments. This generally improves the accuracy and success of changes to production because they Dev team has already made the software work in other environments. It can also reduce the duration of incidents and increase availability of an app – but impacts Segregation of Duties (SoD). This leads to a decision about the trade-off between perceived Risk and Reward that an organization must make.
The SDLC is also a huge issue for organizations. The move from Waterfall based methodologies to Agile or DevOps is not to be undertaken lightly!! It requires new tooling, re-training of technical people AND business people. It means breaking down problems and inter-acting in new ways – and we are generally not good at change!! We all talk about Agile/DevOps successful transitions, but the list of failed attempts is long and often worth studying to avoid those mistakes in the future!
Hi Richard. Thanks for your comment and input regarding DevOps and SDLC! Your comment was very helpful. I was also bit confused with the actual meaning of “DevOps”. From what I understand, it is the continuous improvement and development of a software program. The way I look at it, is that it’s kind of the mergers of the “Development” and the “Operations” together to improve continue software management and quality. I see some similarities with the System Development Life Cycle (SDLC) since both models will also lead to continual improvement and quality assurance of a program.
From this week’s reading from Chapter 1 The Systems Development Environment, I learned more about systems development life cycle (SDLC). SDLC features many phases that mark the progress of the system analysis and design effort. What’s helpful is that in any given phase of SDLC phase, the project can return to an earlier phase if necessary. Something new that I learned about SDLC is that there can be various different ways to utilize the SDLC. Per this book, the five phases of the SDLC are planning, analysis, design, implementation, and maintenance.
The reading from CISA Chapter 3 talks about the different SDLC models: traditional waterfall, v-shaped, and iterative. The traditional SDLC model’s primary advantage is that it provides a template into which methods for the requirements can be placed. With the waterfall methodology usually one phase is completed to start the next. The disadvantage of this method is that small details left incomplete can hold up the entire process. The V-model is an extension of the waterfall method and tests at each stage of development. One advantage of the verification and validation model is that an IS auditor can provide an evaluation of the methods and techniques applied throughout the development phases of the business application life cycle. Whereas, the iterative model is a cyclical process in which business requirements are developed and tested in iterations until the entire application is designed, built and tested. A disadvantage of this model is that it can eat up resources fast if left unchecked.
Hi Priyanka
I agree with your comments on waterfall methodology for SDLC development. I think where I struggled with this methodology is that it felt very “Oz Like” where development teams could basically go forth and develop without checkpoints. Unless the requirements are crystal clear and the vision of the outcome is very defined, the SDLC ended up in trial and error, build and rework. I like the Agile projects where small teams work on small changes with a shared vision. Business and IT can focus on incremental change without the trial and error mode being a factor. Agile is not perfect but it certainly lets the team see their work being used sooner and adjust to feedback more quickly.
As you mentioned, I think the traditional SDLC model is easy for people to start out with because it has the overall milestones and timelines defined. One steps comes after the other. Something starts and finishes before the next thing can start. In that sense it’s easier to tackle and easier to understand. Obviously, though, it has its inefficiencies that agile methodologies can improve upon. Agile’s principles were formed by developers who were unhappy with how long it took to get from the start to the end of a waterfall SDLC.
The reading this week was meant to introduce us to the Software Development Life Cycle and critical methodologies that are used to manage and identify risk with the implementation of new software. Most SDLC processes are managed using one of the project management methodologies for IT projects, either waterfall, verification and validation or iterative. In my experience iterative IT projects allow faster delivery of small capabilities over time as opposed to the waterfall approach where validation does not occur until most of the development work is underway. What I found interesting in the reading was the role of the IT auditor in the SDLC process. IT auditors play a role throughout the project although their focus looks a little different depending on whether the software is developed in house or whether the software is purchased. The IT auditor’s role really seems to engage from the beginning of the project to ensure that the business case is sound, that decisions to buy or build the software reflect the risk associated with that decision. Then as the software decision is implemented the auditor is evaluating project a little differently for purchased versus built software. For purchased software, the auditor is focused on whether the project defines roles and responsibilities, classifies and prioritizes changes using business risk as a criteria, assesses impact of the software change to the organization, implements appropriate review and approvals throughout the project, statuses the project to stakeholders with some frequency and whether the project assessed the impact to data integrity. For built software, the same lens is placed on the project as for purchased software, however, there are a few differences in where the auditor is looking for the project to mitigate IT risk. The auditor also focuses on programming methods including whether IT risk is mitigated through the use of programming standards and best practices, whether online programming facilities or debugging tools are used to solve programming risks. The lens of the IT auditor in the text is an interesting perspective.
Hi Heather,
I agree with your comments on the iterative IT projects. Iterative process usually starts with a simple implementation or just part of the software which is then reviewed in order to identify further requirements. The biggest advantage of iterative process is that it is implemented during the earlier stages of software development process which allows developers and testers to find design related flaws early in the process. It is also more cost effective to change the scope or requirements.
IT Auditor’s role in SDLC project management is definitely an interesting read. The main role of an IT Auditor is to analyze the associated risk and exposures inherent in each phase of the SDLC and ensure appropriate controls have been implemented to minimize risk in a cost-effective manner. IT auditor should also obtain all the documentation from the various phases and attend project team meetings to offer advice to the project team throughout the system development process.
There are several methods of developing a software development lifecycle (SDLC). In the first phase of planning, the organizations need to determine what new or enhance system projects need to develop, which resource they will use, how they will implement the project, and when they will complete the project. After this, the organizations need to analyze what the users’ requirements determination processes perform within the organizational tasks, and they need to involve the current systems to adjust any needs. When they acquire sufficient resources to execute the system, they will start to design process, and they need to ensure that the system can be run on any hardware and software. The fourth phase is implementation. The team will write the coding to run the system, test the new system with both individual programs and the entire system. If it is successful, the team will start to install the new program in the organization. During the installation, they have to train the users and document the procedures. Although the system passes the test during the implementation, it may occur some unexpected issues, so the organization needs maintenance to repair and improve the new system. Sometimes the team may not follow the steps to develop the new system. If there is one phase need to make changes, such as the implementation, the team may need to go back to the analysis phase to do more work. Thus, I think we need to understand how to not only the order but also use these phrases.
I think that the IT auditors as the communication bridge between the technicians and the management, and they can help the business to achieve the objectives. For example, the IT auditors can give some advice to adjust any issue in the system development process. Since the IT auditors must have a thorough understanding of how to align business strategy and IT strategy, they can help the business to improve the risk management while they are reviewing the processes. Finally, the IT auditors can provide the most effective controls to mitigate the risks during the system development processes.
Information system analysis and design is an organizational process that involves business and system professionals’ development and maintenance of the information system. Therefore, as explained by the text Modern Systems Analysis and Design by Valacich and George “…analysis and design of information systems is based on your understanding of the organization’s objectives, structure, and processes, as well as your knowledge of how to exploit information technology for advantage.” SDLC takes on a combination of tools, techniques and methodologies used to design the system. There are 5 phases in the system design lifecycle (PADIM); planning, analysis, design, implementation, and maintenance. We looked at traditional waterfall approach and the agile approach. A traditional approach would be best when a system design involves life or death. The drawbacks are that it is time consuming, lacks user involvement, and inflexible. A phase in the SDLC would end and another begin once a milestone was accomplished. Agile approach is more flexible, has a lot more user involvement, it uses resources efficiently. Extreme programming uses two-person programming teams and has consumers on site during the development process. Planning, analysis, design and construction are combined in a single phase activity. In this method programmers write and test the code. Usually, the code is integrated into the system soon after it is developed. Benefits of this concept is that it helps the team work better and use resources better, communication is increased, high quality code.