In: Computer Science
Building security into the design phase of the software development lifecycle (SDLC) is important to be successful in securing software. In this forum, you will research the best secure software design methodologies to prevent vulnerabilities and share your findings with the class.
While a security method may work well for one organization, the same approach may not work well for other organizations. However, there should be some best practices we should follow to be successful in the SDLC phases
-------------------------------- Please Upvote!!! Thank You ..;) ---------------------------------
Explain what implications we may face if we don’t identify and mitigate security issues in the SDLC phases.
1. Injection flaws
Injection flaws result from a classic failure to filter untrusted input. It can happen when you pass unfiltered data to the SQL server (SQL injection), to the browser (XSS – we’ll talk about this later), to the LDAP server (LDAP injection), or anywhere else. The problem here is that the attacker can inject commands to these entities, resulting in loss of data and hijacking clients’ browsers.
2. Broken Authentication
This is a collection of multiple problems that might occur during broken authentication, but they don’t all stem from the same root cause.
3. Cross Site Scripting (XSS)
This is a fairly widespread input sanitization failure (essentially a special case of common mistake #1). An attacker gives your web application JavaScript tags on input. When this input is returned to the user unsanitized, the user’s browser will execute it. It can be as simple as crafting a link and persuading a user to click it, or it can be something much more sinister. On page load the script runs and, for example, can be used to post your cookies to the attacker.
4. Insecure Direct Object References
This is a classic case of trusting user input and paying the price in a resulting security vulnerability. A direct object reference means that an internal object such as a file or database key is exposed to the user. The problem with this is that the attacker can provide this reference and, if authorization is either not enforced (or is broken), the attacker can access or do things that they should be precluded from.
5. Security misconfiguration
The web servers and applications that have been misconfigured are way more common than those that have been configured properly. Perhaps this because there is no shortage of ways to screw up. Some examples:
Discuss a “right” approach to securing SDLC phases so that we can identify software issues early and mitigate them while designing software.
PREVENTION
Limit Privilege. Don’t give any user more privileges than he absolutely needs to do his job. Just as you wouldn’t give a random employee the keys to the CEO’s office, don’t give him a password to the CEO’s files.
Secure the Weakest Link. Spend your security budget securing the biggest problems and the largest vulnerabilities. Too often, computer security measures are like planting an enormous stake in the ground and hoping the enemy runs right into it. Try to build a broad palisade.
Use Choke Points. By funneling users through choke points (think firewalls), you can more carefully secure those few points. Systems that bypass these choke points, like desktop modems, make security much harder.
Provide Defense in Depth. Don’t rely on single solutions. Use multiple complementary security products, so that a failure in one does not mean total insecurity. This might mean a firewall, an intrusion detection system and strong authentication on important servers.
Fail Securely. Design your networks so that when products fail, they fail in a secure manner. When an ATM fails, it shuts down; it doesn’t spew money out its slot.
Leverage Unpredictability. You know your network; your attacker doesn’t. This is your big advantage. Make his job harder by disguising things, adding honey pots and booby traps, etc.
Enlist the Users. Security can’t work if the users aren’t on your side. Social engineering attacks are often the most damaging of any attack, and can only be defended against with user education.
Embrace Simplicity. Keep things as simple as absolutely possible. Security is a chain; the weakest link breaks it. Simplicity means fewer links.
Design for security involves designing a secure system architecture, following good practice for secure systems design, and including functionality to minimize the possibility of introducing vulnerabilities when the system is deployed.
To support secure deployment you should provide a way of displaying and analyzing system configurations, localize configuration settings so that important configurations are not forgotten, minimize default privileges assigned to system users, and provide ways to repair security vulnerabilities.
Guidelines for secure systems engineering :
1 Base security decisions on an explicit security policy
2 Avoid a single point of failure
3 Fail securely
4 Balance security and usability
5 Log user actions
6 Use redundancy and diversity to reduce risk
7 Validate all inputs
8 Compartmentalize your assets
Design for deployment
The deployment of a system involves configuring the software to operate in an operational environment, installing the system on the computers in that environment, and then configuring the installed system for these computers .
Configuration may be a simple process that involves setting some built-in parameters in the software to reflect user preferences. Sometimes, however, configuration is complex and requires the specific definition of business models and rules that affect the execution of the software. It is at this stage of the software process that vulnerabilities in the software are often accidentally introduced. For example, during installation, software often has to be configured with a list of allowed users. When delivered, this list simply consists of a generic administrator login such as ‘admin’ and a default password, such as ‘password’. This makes it easy for an administrator to set up the system. Certainly, good management practice can avoid many security problems that arise from configuration and deployment mistakes. However, software designers have the responsibility to ‘design for deployment’. You should always provide built-in support for deployment that will reduce the probability that system administrators (or users) will make mistakes when configuring the software.
I recommend four ways to incorporate deployment support in a system:
1. Include support for viewing and analyzing configurations : You should always include facilities in a system that allow administrators or permitted users to examine the current configuration of the system.
2. Minimize default privileges : You should design software so that the default configuration of a system provides minimum essential privileges. This way, the damage that any attacker can do can be limited.
3. Localize configuration settings : When designing system configuration support, you should ensure that everything in a configuration that affects the same part of a system is set up in the same place.
4. Provide easy ways to fix security vulnerabilities : You should include straightforward mechanisms for updating the system to repair security vulnerabilities that have been discovered.
-------------------------------- Please Upvote!!! Thank You ..;) ----------------------------------