SOFTWARE SECURITY Put together by Meenakshi Mani Tanvi Shah WHAT IS SOFTWARE SECURITY Its all about building secure software The process of designing building and testing software for security Taking the pro active approach building security INTO the software as opposed to securing it after building it JUST TO CLARIFY SOFTWARE SECURITY SECURITY SOFTWARE WHY GO IN FOR SOFTWARE SECURITY 1 Good secure software is the need of the day Reduction in the expenses incurred in Fixing bugs in a software Market value if your software isn t secure it is not going to stay in the market WHY GO IN FOR SOFTWARE SECURITY 2 REASONS FOR INSECURE SOFTWARE Reliance on networked devices Easily extensible systems Growing internet connectivity makes it easier for hackers Extensions increase scope for software vulnerabilities Increasing complexity of the software needed to be built Windows XP had 40 million lines of code WHAT CAN WE DO Be pro active in building security into the software from ground up Important to include security into every phase of the Software Development life cycle WHY Software security is a system wide issue that involves both building in security mechanisms and designing the system to be robust You can t spray paint security features onto a design and expect it to become secure Most approaches in practice today involve securing the software AFTER its been built Not the best approach and certainly not effective enough as has been proved we still have issues with our software being meddled with by hackers don t we BUILDING SECURITY IN 1 BUILDING SECURITY IN 2 Security requirements deal with abuse cases how the system will react under attack and inject requirements which will address that Take into account the various security principles while charting out the basic design or architecture Risk analysis to identify the risks Will include external review BUILDING SECURITY IN 3 At the code level make use of static analysis tools tools that can search code for common vulnerabilities like buffer overflow Security testing must involve two strategies Testing security functionality with standard test techniques Risk based security testing based on attack patterns and models BUILDING SECURITY IN 4 Penetration testing Good to understand the behavior of your software in a real time environment Security breaks Observe and study them Recycling knowledge from attacks and exploits back into the organization SECURITY DESIGN PRINCIPLES YES WE HAVE PRINCIPLES TO GO BY 10 principles which go by the 90 10 rule Avoid 90 of the potential problems by following 10 simple rules PRINCIPLE 1 SECURE THE WEAKEST LINK Your system is as secure as its weakest link Secure all parts of your system from bottom up All the cryptography in the world will not help if there is an exploitable buffer overflow in the software PRINCIPLE 1 CONT Perform Risk analysis iteratively and keep identifying potential risk areas and fixing them Stop iterating at some point when it feels that all components are within an acceptable risk threshold PRINCIPLE 2 DEFENSE IN DEPTH Manage risk with multiple layers of defensive strategies If the error is not caught my one layer of defense it will be caught by the next layer A bank is typically more secure than a convenience store security cameras guards a vault that s a 3 tier defense already PRINCIPLE 3 SECURE FAILURE Any system having complex functionality will have failure modes Problem failures can cause insecure behavior in the system All someone needs to do is force failure to take advantage of the system Thus make sure that if and when your system fails it fails in a secure manner PRINCIPLE 4 LEAST PRIVILEGE Accesses to perform operations within the system should be given out very specifically and for specific amount of time Coding with the attitude someday I may want to perform these operations so lets set up these privileges for convenience is a very bad idea PRINCIPLE 5 COMPARTMENTALIZE The idea behind this to essentially minimize the damage that can be done if a part of your system is compromised This will make implementation of the previous principle easier However use compartmentalization in moderation or you will end up with lots of little fragments of software that you cannot manage PRINCIPLE 6 SIMPLICITY The KISS principle Keep it simple stupid But don t oversimplify things Designing a website online involving data transactions without using encryption not a wise idea As simple as it can get while still meeting your security requirements Reuse of components A LITTLE DIVERSION Choke Points Design all the security critical operations to be funneled through specific number of choke points Monitoring anomalies becomes easier Usability The hardest and most important task finding a balance between security and usability PRINCIPLE 7 PROMOTE PRIVACY Privacy is of primary importance especially for online software applications Trade off Privacy against usability Eg storing credit card numbers in the website database and auto prompting a returning user high usability low privacy low security PRINCIPLE 8 IT S HARD TO HIDE SECRETS No matter how hard you try to hide your data there is always going to be someone who will find a way to break through to it Reverse engineering is not that difficult So keep that in mind while chalking out your design will my sensitive data still be safe if people know how my system works PRINCIPLE 9 DO NOT EXTEND TRUST EASILY Don t blindly assume that all end users of your software are going to be trustworthy Social engineering attacks customer support Any entity that you are trusting with sensitive data you are implicitly trusting anyone that the entity will in turn trust PRINCIPLE 10 TRUST THE COMMUNITY It looks contradictory to the previous principle sometimes you need to use your own discretion This principle applies as long as you are sure that the community is working on the security aspects of the components that you want to use and is dedicated to it Eg in cryptography it is considered bad to use an algorithm that is not publicly known and has been scrutinized SOME OO PRINCIPLES YOU CAN USE TO IMPLEMENT THESE PRINCIPLES Encapsulation Abstraction Single Responsibility Principle GOOD PRACTICES AND APPROACHES 1 Training and education The most important people involved are the design architects developers and testers Essential to train them to think not just functionality but also security Make security an integral part of learning how to program GOOD PRACTICES
View Full Document
Unlocking...