For this week’s Discussion, we consider Application (Software) Development. Answer at least one of the following questions:
- During which phase should Information Security be included? How would you explain to someone that Information Security has a role without a finalized product yet?
- Choose one of the popular software development methodologies, such as Scrum, Agile, or Waterfall; how does the choice of the methodology affect Information Security concerns?
Elizabeth V Calise says
1. During which phase should Information Security be included? How would you explain to someone that Information Security has a role without a finalized product yet?
Integrating security into the application development cycle is not an all-or-nothing decision, but more of a process of negotiation within the policy, risk and development requirements. It is crucial to engage the security team(s) (in-house or outsourced) from the very beginning. During the initial phase of application development allows the security team to determine the security areas necessary to satisfy policy and risk tolerance in the context of the organization.
2. How would you explain to someone that Information Security has a role without a finalized product yet?
Below is how I would explain to someone that security has a role from the initial phase. Except below shows security involvement from the very beginning before development takes place to the end where the application is launched and in use.
Security involvement could possibly be broken out into:
1. Initial Review – The security team can assess initial risks.
2. Threat Modeling – The security teams works with developers to identify areas dealing with sensitive information. Then map out information flow.
3. Design Review – An important step in identifying potential security risks at the early development stage.
4. Code Review – After unite testing is complete, security testing can take place against units.
5. Risk Assessment – A risk assessment to be done prior to deployment.
6. Risk mitigation – Involves prioritizing, evaluating and implementing the controls the security teams identifies as necessary to mitigate vulnerabilities discovered during the area before.
7. Benchmark – Benchmark the application against industry standards to deliver a scorecard.
8. Maintenance – Continue to have periodic security checks of all critical apps and controls
Dima Dabbas says
Elizabeth,
Your example clearly states how security is involved from the initial phase of the project till the final phase. Having security as one of the considerations in each phase helps ensure that the final application can be used by users and that their data and information is protected. There maintenance phase is an important phase that some organizations ignore even though it is essential to ensure that security is up to date for the organization. There should always be maintenance checks periodically to ensure that there are no new risks or existing risks that may threaten the organization.
Jonathan Duani says
Elizabeth,
I love the breakdown you used here with the explanation for the different sections. I think the best thing was how you broke down each individual section and put a little blurb about each one, It is a really good road map to give to someone who does not really understand security and give them a broad overview.
Ahmed A. Alkaysi says
During which phase should Information Security be included? How would you explain to someone that Information Security has a role without a finalized product yet?
Information Security needs to be involved from the start of any project, whether it be traditional waterfall or agile methodology. Waiting for a product to be finalized before getting someone from InfoSec involved will be too late. By integrating InfoSec from the start, they will be able to provide valuable information in regards to the security of the product. This might require the product to be redesigned. If the product is finalized before InfoSec comes into the picture, and determine that the way it has been architected is flawed, the organization will have to redo the product ultimately costing the organization more money. Not including InfoSec from the start might also increase the risk of vulnerabilities throughout the process. The dependencies related to the product will now have an inherent risk due to the lack of initial security analysis conducted on the product from the onset. This might not be caught even after InfoSec comes in at the last second, since these might have also gone through design changes.
Dima Dabbas says
Ahmed,
You bring up interesting points in your response. Like you mentioned, if organizations don’t consider security from the beginning in the initial phases, not only will the organization be under risk but it will also end up impacting the organization financially as more money will need to be spent to redesign the project and include security. This may lead to disastrous results which is the reason security should be one of the first considerations in each phase of the project.
Duy Nguyen says
During which phase should Information Security be included? How would you explain to someone that Information Security has a role without a finalized product yet?
OWASP’s S-SDLC incorporates information security into all stages of the system development lifecycle. The framework consists of tips, guilds, checklists, and best practices for developers to adopt security into their development. This methodology’s overall goal is to reduce vulnerabilities and raise the overall security level of application development.
To justify the need for security in the development lifecycle is to outline the weakest link in any application, which is the end-user. There’s no predicting how or what an end-user or threat agent will exploit a security hole in an application. The only way to reduce risks to a critical application is to implement an effective security mindset throughout the development of that application. The costs of implementing security aspects into SDLC will many times be less than the cost of an incident. In addition, identifying an exploit/bug in development is more cost-effective than discovering it in later phases or in the final product.
Elizabeth V Calise says
Duy,
I like how you brought up the end-user in this. It can be almost impossible to avoid end-user mistakes. What one can do is to ensure security has been invovled in the project since day one. Incorporating security from the beginning decreased the chance of possible threats coming up in the application. Removing those threats from the beginning can help decrease the chances of an end-user “istake”. End users can do stupid things and as security professionals, we do not have complete control over that. What we can do to help is to ensure are applications are as secure as possible by being apart of porjects from the beginning and not till the very end.
Ahmed A. Alkaysi says
I agree that the end-user is the weakest link in any application. When designing a product, the security professional must think in terms of what the end-user can do, either by mistake or on purpose. By doing this, they will be able to mitigate the risks associated with the end-user.
Folake Stella Alabede says
1. During which phase should Information Security be included? How would you explain to someone that Information Security has a role without a finalized product yet?
This was the opening topic to the reading for this week (Chapter 20 – Software Development Security).
Security should be considered at every stage of a system’s development, including the software development process. Programmers should strive to build security into every application, with greater security provided to critical applications and those that process sensitive information.
Also, Information Security has a role without a finalized product yet as it is “extremely” important to consider the security implications of a software development project from the early stages because it’s much easier (and probably less expensive and less costly if done earlier on) to build security into a system than it is to add security to an existing system.
This week alone, I have read a number of cases of breaches and hacks, like the 7-Eleven hack in Japan, the BA fines due to some security flaws, UK’s Largest Forensics Firm that Paid Ransom to Attacker etc. All these breaches were due to some security flaws, and I bet that it would have been easier and definitely cheaper to have built this security in than it is to fix it/pay ransoms /pay customers back.
An article I was reading “Wipe Away the Threat of Wiper Attacks” on wiper attacks explains that resisting wiper malware requires putting defenses in place before attackers come calling. “It is time for strong authentication, least privilege access control – or at least ‘read-only’ or ‘execute-only’ – and end-to-end application layer encryption. In addition to implementing multi-factor authentication, make sure that legacy protocols that don’t support MFA are either disabled or tightly restricted.”
The new evolving trend is the Integration of Information Risk Management into Business Risk Management
Dima Dabbas says
Stella,
As you stated in your response, security is critical. It is time for organizations to step up and make decisions of how their organizations should handle security in new and existing projects and applications. It is also very important to classify each application and determine the data and information it handles as well as its sensitivity. The more sensitive information that the application handles, the more secure the application should be. The data breaches and incidents we are hearing about all prove that we need to add more security into our daily tasks.
Scott Radaszkiewicz says
During which phase should Information Security be included? How would you explain to someone that Information Security has a role without a finalized product yet?
Security is a huge concern when developing software. Considering the system development life cycles that are popular today, I believe that security should be a focus at each phase of the development. One can not say that security should only be considered at one level. If you consider security at only the development phase, but then don’t consider it while testing, then there could be issues with the security you designed into the system.
If you test for security on the finalized product only, there could be holes built into the system. A programmer could code back doors into the program, that would not be detected in final testing. Testing for security has to happen at all levels so that no actor, internal or external, can compromise the security of the system.
Oby Okereke says
Hi Scott:
I particularly like how to addressed implementing Security during the testing phase of software development. Only an organization that has yet to experience a data breach caused by poor application will gainsay the fact that not only is Testing for security during the Testing phase of a software development important but it is all so important in all Application development phases.
Small wonder Agile as a project development methodology is gaining an uncontrollable widespread. My current organization has adopted Agile in most application development effort as it allows developers to go back and correct any issues compared to previous utilized Waterfall methodology which makes it entirely difficult to correct any defect talk less of retrofitting security. As a security professional managing poorly developed applications that where security was an afterthought, the aspect of dealing with waivers, risk acceptance and compensating controls becomes a never-ending arduous task.
Jonathan Duani says
Scott, Yes! I totally agree with your statement about “If you consider security at only the development phase, but then don’t consider it while testing, then there could be issues with the security you designed into the system.” I think it is important to factor in security all the way though. That way you are checking and making sure the risks are mitigated all the way through and the vast majority of issues are found.
Ahmed A. Alkaysi says
Scott, I definitely agree that security testing must happen in all phases. A lot of this testing has become automated, especially in the DevOps world. Dynamic and static code analysis can be conducted within a continuous delivery pipeline that can look for many of the vulnerabilities that might have otherwise made it into production.
Dima Dabbas says
1. During which phase should Information Security be included? How would you explain to someone that Information Security has a role without a finalized product yet?
Information security should be considered in each phase of the SDLC. This will help ensure that the finalized product will be secure. For a product to be finalized and presented to customers, it needs to be tested to ensure that the product meets the business demands it was created for as well as that it is secure to be used by customers who trust that this product will protect their information. A product can not be finalized if security isn’t one of the checklist items in each phase. Including security in each phase helps integrate development with security as well as consider the many issues that may arise if security was considered after the development phase was complete. Security is essential as it is becoming a continuous concern to organizations. Integrating security from phase one helps detect any flaws early in the process which will lead to cost reduction because of the early detection and resolution of issues therefore reducing the business risks within the organization.
Brock Donnelly says
Our book put it simply, information security should be involved throughout the entire software development process. It is much easier to build security for the beginning than to add it afterward. How successful they are at achieving the best security might depend upon the chosen methodology. A waterfall methodology cascades from one stage to the next but does not allow for stage hopping. SO it is difficult to go forward or backward without remaining sequential. The spiral model could still be thought of as fluid, like a drain. While its processes are an encapsulated version of the waterfall model it improves on IS because multiple stages are contained within its spiral development allowing for more fluid back and forth between development alterations before it proceeds to the next section of the spiral. The spirals here also allow for more prototyping. If you would like your software to be robust and secure then you need to make the effort for modifications easier. The agile methodology provides a high amount of variation for success. It has a manifesto like a malicious recluse yet its principals if followed by any process would achieve good results. While the principals seem like a given and simple they require being written down as well as upper management support. They allow for a progressive working environment that focuses on the end users experience while achieving all of the companies goals including security.
My favorite of the manifesto:
Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
Oby Okereke says
Hi Brock:
Don’t you just like the agile methodology ? I like how you drew upon the Agile methodology which reminds me of my Scrum class. As a scrum master though currently not practicing scrum per se in my current role, I appreciate the agile methodology even more one of its manifesto value which reads thus “Responding to Change over following a plan”. The ability for software developers to retreat and make the needed changes is huge value especially if a secure and robust applications/software is desired in our IT environments.
Responding to change is a valuable tool for creating applications especially with the spate at which applications and technologies, customer needs changes. It is possible to end up with an application that may not meet the current market need if the waterfall methodology was adopted in the development of an application as it rarely allows new requirements once decisions have made per the project design et al.
Elizabeth V Calise says
Hi Brock,
I like how you brought agile and waterfall into the mix, especially since I am a certified scrum master. I 100% agree with you that the methodology you use can have an impact on the implementation of security. Waterfall has its limits. To go back and forth with the project using waterfall does not work and that raises concerns. Agile allows for change no matter what stage you are in. It is important to be able to adopt change when it comes to incorporating security in the application, not just the development.
Jonathan Duani says
Elizabeth,
I like how you said the methodology you use could impact the implementation of security. I do think that there are definitely better solutions to use when implement a project that incorporates security, however wouldn’t every project implement security? SO what do these methodologies exist if they do not work well with security?
Ahmed A. Alkaysi says
I really like that piece from the manifesto. From experience, many individuals are more motivated in an agile methodology as opposed to waterfall due to the product ownership assigned to them. Generally, in an agile or DevOps approach, teams are assigned a product that they will continue to work on until its retirement. Doing it this way will help establish the accountability and team members feel that they are in it for the long haul.
Jonathan Duani says
I think security should be considered and incorporated into every step of the design process. This will allow for easier implementation of security into the code as it is being developed. When developers take the time to implement security features as they are designing the product it will be much more solid in a security regard. This is due to the fact that once a developer has finished developing the product going back through an adding security features might actually cause more problems because it will be an after though. The features implemented after the fact could break the program all together or cause massive holes that were not thought about till it was to late. Even though a lot of companies do this to meet deadline cause something factoring the security take a lot more time it can really hurt them in the long run
Sheena L. Thomas says
During which phase should Information Security be included? How would you explain to someone that Information Security has a role without a finalized product yet?
Information Security should be included during each phase of the process starting with the Initiation phase. Security should be a major aspect of the system and business development process.
According to Ernest Mougoue of synopsys.com, “In the past, it was common practice to perform security-related activities only as part of testing. This after-the-fact technique usually resulted in a high number of issues discovered too late (or not discovered at all). It is a far better practice to integrate activities across the SDLC to help discover and reduce vulnerabilities early, effectively building security in.
It is in this spirit that the concept of the secure SDLC arises. A secure SDLC process ensures that security assurance activities such as penetration testing, code review, and architecture analysis are an integral part of the development effort. The primary advantages of pursuing a secure SDLC approach are:
• More secure software as security is a continuous concern
• Awareness of security considerations by stakeholders
• Early detection of flaws in the system
• Cost reduction as a result of early detection and resolution of issues
• Overall reduction of intrinsic business risks for the organization”
Sheena L. Thomas says
https://www.synopsys.com/blogs/software-security/secure-sdlc/
Frederic D Rohrer says
During which phase should Information Security be included? How would you explain to someone that Information Security has a role without a finalized product yet?
Security should be included in the very first draft of a software concept. Planning and organizing is incredibly important in software development and can make or break the product. Therefore security should be discussed both as a limitation and feature of the software right away.
I would explain that while white-box testing and application is nice, the real security comes from its design. It is also much cheaper to create well-thought out software in the long run.
Choose one of the popular software development methodologies, such as Scrum, Agile, or Waterfall; how does the choice of the methodology affect Information Security concerns?
The two methodologies that differ the most in security are Scrum and Waterfall. In Scrum updates are made in frequent, small deliveries and unit testing is done at the end of every iteration (or sprint). In Waterfall everything is designed up front and released and tested after all development is completed. Waterfall makes security design and testing much easier, as the scope is well defined and documentation is usually done up front and to exhaustion. In Scrum cycles the scope can often adopt to the client needs as they change, then changes are made frequently up to the last point before release. Feature-sets are not defined up front which makes testing harder. On the other hand it is much easier to change software in Scrum, so that if a security vulnerability is discovered it is easy to correct.
Jonathan Duani says
Frederic,
I like the breakdown you used on Waterfall and Scrum. I do agree that waterfall could make the security implementation much easier however, i think using a scrum approach could be beneficial because if the customer ideas are always changing and getting better you can easily implement something new. When new things get proposed you start with the security aspect right away so it does not mess up the integration of the security in the project.
Rommel R. Miro says
During which phase should Information Security be included? How would you explain to someone that Information Security has a role without a finalized product yet?
My take is that Information Security must be included or be had in mind from the beginning of the software development lifecycle. Having it beyond this phase makes in an afterthought. By including it early on, it will facilitate smoother integration of security-related modules and logic into the code and applications being or about to be developed. If information security is a requirement, it will be less likely for developers to miss it or not prioritize it high enough when building their application and programs. Since the typical focus is the logic of the business requirement or primary function of the application, it is not uncommon to see security handled as something with less priority or importance. Inserting additional code related to security after the other functions are written can also mean re-doing other testing and validation steps, depending on protocol. By including information security considerations from the beginning, you will most likely save time in the long run and end up with a more secure application to boot.
Steve Pote says
I come from Software Development. Like any framework, security should be ~baked in~ from planning. Too often software projects, especially low priority, low funding ones are built like the Johnny Cash song “One Piece at a Time”, where car parts from several decades are assembled into an ugly, if functional, mess.
Planning the security on my home construction required knowing where the doors would be before the foundation was poured. You could fit them in, one piece at a time, or plan and save time money and ugly mess embarrassment.
Moving from metaphor, there is only an ugly mess of plated-on code moving from an unsecured development version to a retroactively secured production environment.
In all cases of metaphor and reality the baked-in models suggest better means to unit test and to build with forethought and patching in mind.
The Project Management methodologies show security has moved from “Oh crap!” sprints to more mature models
Choice has a lot to do with resources and time…Waterfall resembling the car assembly, major components waiting for others in a critical order.
Agile-Scrum more closely resembles the house construction with simultaneous independent tasks converging