SOFTWARE SECURITY Put together by – Meenakshi Mani Tanvi ShahWHAT 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.SOFTWARE SECURITY ≠ SECURITY SOFTWARE !! JUST TO CLARIFY ..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 marketWHY GO IN FOR SOFTWARE SECURITY(2)REASONS FOR INSECURE SOFTWARE Reliance on networked devices Growing internet connectivity makes it easier for hackers Easily extensible systems 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 reviewBUILDING 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 modelsBUILDING 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 softwarePRINCIPLE#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 ideaPRINCIPLE#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 componentsA 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 usabilityPRINCIPLE#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
View Full Document
Unlocking...