Security Awareness

Software Security

• Software Security is an idea implemented to protect software against malicious attack and other hackers risk so that software continues to function correctly under such potential risks.
• Security is necessary to provide integrity, authentication and availability
• Confidentiality : unauthorized users cannot read information.
• Integrity : unauthorized users cannot alter information.
• Availability : Authorized users can only access the information.

Assets threats and Vulnerabilities

• Asset :
• An asset is a resource of value.Assets can be very perspective so its important to think of them in terms of what you want protected as well as what an attacker may be interested in.
• Threat :
• A threat is an undesired event that may compromise an asset or objective, or produce an undesired outcome.It may or may not be malicious.
• Vulnerability :
• A vulnerability is a weakness in your system, or in a security control, that makes an exploit possible.
• Attack :
• An attack is an action that utilizes one or more vulnerabilities to realize a threat.
• Counter Measure :
• A counter measure addresses a vulnerability to counteract a risk. A counter measure directly addresses the factors that contribute to a threat, such as an improving design, implementation or deployment.
• Security Control :
• A security control, also known as a safeguard is a process or policy put into place in order to reduce threats to an acceptable level.

Computer Criminals

• Hackers :
• White Hat
• Grey Hat
• Black Hat
• Malicious individuals within the victim organisation.
• Script Kiddies : Unconsolidated computer users who knows how to execute programs.

Leading Threats

• Virus
• Worm
• Trojan Horse/Logic Bomb
• Social Engineering
• Rootkits
• Botnets/Zombies

Secure Development Life cycle

• Training
• Core Security Training.
• Requirements
• Establish Security Requirements.
• Create quality gates/Bug bars.
• Perform security and privacy Risk assessments.
• Design
• Establish Design Requirements.
• Perform Attack Surface Analysis/Reduction.
• Use Threat Modelling.
• Implementation
• Use approved tools.
• Depreciate unsafe functions
• Perform Static Analysis
• Verification
• Perform Dynamic Analysis
• Perform Fuzz Testing
• Conduct Attack Surface Review
• Release
• Conduct an Incident Response Plan
• Conduct Final Security Review
• Certify Release and Archive
• Response
• Execute Incident Response Plan

Information Security

• Information is an asset which like other important business assets has value to an organization and consequently needs to be suitable protected.
• Information Security is the practice of defending information from unauthorized access , use , disclosure,disruption,modification,inspection,recording or destruction.

Information Security Domains

• Access Control
• Application Security
• Business Continuity Planning and Disaster Recovery Planning
• Cryptography
• Legal Regulations Compliance and Investigations
• Operations Security
• Physical(Environmental) Security
• Security Architecture and Design
• Risk Management
• Network Security

Application Security

• It is the design and implementation of application functionality intended to ensure the confidentiality, integrity, and availability of protected information and systems.
• Application Security is not the same as Network Security.
• Network Security focuses on restricting communication paths between systems.
• Software security focuses on the run time logic within applications and the processing of data passed inside of an allowed communication path.
• Application Security is needed because
• 70% of attacks are at application level.
• 95% of all vulnerabilities are in software  - NIST
• 7 out of 10 websites have serious vulnerabilities(White Hat Security).
• 62% of organisations have experienced a security breach in the past 12 months.

Elements of Security

• Confidentiality
• Integrity
• Authenticity
• Authorization
• Availability
• Non-repudation

Secure Software Development Lifecycle

• Software Development Lifecycle
• The software development lifecycle(SDLC) is a framework defining tasks performed at each step in the software development process.
• Secure Software Development Lifecycle
• Incorporating the security from the requirement stages to deployment.
• Advantages of S-SDLC
• More secure software
• Reduce the Costs
• Help to address compliance requirements.
• Steps of S-SDLC
• Requirements
• Security Requirements
• Setting up phase gates
• Risk Assessment
• Design
• Identify Design
• Security Requirements
• Architecture and Design Reviews
• Threat Modelling
• Coding
• Coding best Practices
• Perform static Analysis
• Testing
• Vulnerability Accessment
• Fuzzing
• Deployment
• Server Config Review

Requirements Phase

• Establish Security Requirements
• Defining and integrating security and privacy requirements early helps make it easier to identify key milestones and deliverables and minimise disruptions to plans and schedules.
• Create quality Gates/Bug Bars
• Defining minimum acceptable levels of security and privacy quality at the start helps the team understand risks associated with security issues, identify and fix security bugs during development, and apply the standards throughout the entire project.
• Perform Risk Assessments
• Examining software design based on costs and regulatory requirements helps a team identify which portions of a project will require threat modelling and security design reviews before release and determine the privacy impact rating of a feature, product or service.

	Internet Facing	Non Internet Facing
Critical App	High Risk	High Risk
Non Critical App	Medium Risk	Low Risk

Design Phase

• Establish Design Requirements
• Considering security and privacy concerns early helps minimise the risk of schedule disruptions and reduce a project's expense.
• Attack Surface Analysis/Reduction
• Reducing the opportunities for attackers to exploit a potential weak spot or vulnerability requires throughly analysing overall attack surface and includes disabling or restricting access to system services, applying the principal of least privilege , and employing layered defences wherever possible.
• Use Threat Modelling
• Applying a structured approach to threat scenarios during design helps team more effectively and less expensively identify security vulnerabilities determine risks from those threats and establish appropriate mitigations.

Threat Modelling

• Secure software starts with an understanding of the threats that pose a risk to your application.
• A threat is what an attacker might try to do to a protected resource in the system.
• A vulnerability is a specific way that a threat is exploitable, based on an unmitigated attack path.
• Threat modelling helps us to create secure applications. It allows us to enumerate and understand key assets, risks and potential design vulnerabilities that exist in our application.
• Revise your threat models periodically to account for new threats resulting from new and evolving attack techniques.
• In order to make most impact threat modelling should be performed in the architecture and design phase.Threat modelling can be started as soon as our security objectives are understood and we have an application architecture in place.
• You can use threat modelling to identify threats and vulnerabilities that are relevant for our application and determine counter measures to mitigate vulnerabilities.
• Threat modelling helps us to update and improve iteratively when our when our security objectives change, when our design changes and during implementation testing and deployment.
• In addition we can use threat modelling to identify specific considerations such as 
• Legal requirements : SOX,GLBA,HIPAA,SB1386, and more on the horizon.
• Safety requirements.
• Contractual requirements and customer needs.

Identifying Assets

• Security objectives are goals and constraints related to confidentiality, integrity, and availability of data and application.
• Security objectives are determined based on following criteria
• What client data do you need to protect?
• If our application uses client sensitive data such as passwords, customer account details including personalisation information, financial history& transaction records, customer credit card numbers, bank details, or travel itineraries ?
• Do you have compliance requirements?
• These may include security policy, privacy laws, regulations and standards.
• Do you have specific quality of service requirements?
• Quality of service requirements includes availability and performance requirements.
• Are there intangible assets that you need to protect?
• Intangible items include your company's reputation trade secrets, and intellectual property.
• Examples of common security objectives
• Prevent attackers from obtaining sensitive information, prevent DOS and meet service level agreements for application availability etc.

Documenting Architecture

• In this step, you outline what your web application does.Your goal is to identify your application's key characteristics, functionality and clients.
• Create an application overview.
• Draw the end to end deployment scenario.
• Identify roles.
• Identify key usage scenarios.
• Identify technologies.
• Identify application security mechanisms.

Draw the end to end deployment scenario

• Use a white board to draw the end-to-end deployment scenario.
• Our deployment diagram should generally include the following
• End to end deployment topology.
• Logical layers.
• Key components
• Key services
• Communication ports and protocols
• Identities
• External Dependencies

• Identify Roles
• Identify your applications roles that is, identify who can do what within your application.
• Identify Key Usage Scenarios
• What are the important features of your application?What does it do?
• Identify Technologies
• Operating Systems
• Webserver Software
• Database Server Software
• Technologies used in the presentation,business, and data access layers.
• Development Languages
• Identify Application Security Mechanisms
• Input and data validation
• Authentication
• Authorization
• Configuration Management
• Sensitive Data
• Session Management
• Cryptography
• Parameter Manipulation
• Exception Management
• Auditing and Logging

Decomposing the App

• In this step, you break down your application to identify trust boundaries, data flows,entry points, and exit points.
• The more you know about the mechanics of your application, the easier it is to uncover threats and discover vulnerabilities.To decompose your application.
• Identify trust boundaries.
• Identify data flows.
• Identify data points.
• Identify exit points.

Identifying Threats

• When you are considering threats it is useful to ask questions such as these.
• How can an attacker change authentication data?
• What is the impact if an attacker can read the user profile data?
• What happens when access is denied to the user profile database?
• You can group threats into categories to help you formulate these kinds of pointed questions one such model is STRIDE.
• Spoofing Identity
• Tampering with data
• Repudiation
• Information disclosure
• Denial of Service
• Elevation of Privilege

STRIDE Model

• Categorising Threats - STRIDE Model
• Spoofing Identity
• A banks website may be spoofed.
• Tampering with data
• Changing network packets
• Repudiation
• Someone claims that he didn't send the suspicious mail
• Information Disclousure
• Accessing another user password
• Denial of Service
• Preventing customers from accessing a website
• Elevation of Privilege
• If someone who should only have the read only access to some files is able to edit the files as well.

Example Techniques to Mitigate Threats

• Spoofing Identity
• Authentication,protect keys and Threats.
• To mitigate spoofing threats , you should design software to always authenticate users, other systems, and code prior to performing any sensitive operation.
• To authenticate users or machines :
• Basic authentication
• Digest authentication
• Cookie authentication
• Kerberos authentication
• Public key Infrastructure(PKI) systems such as SSL/TLS and certificates
• IPSec
• To authenticate code or data
• Digital Signatures
• Message authentication codes
• Hashes
• Tampering with Data
• Access Control,Hashes,Digital Signatures,MAC(Message Authentication Codes),Write Once Storage
• To defend against data tempering threats,your software should include measures for enforcing access control and detecting loss of data integrity such as :
• Access Control Lists(ACL),fine grained access control,rule-based access control, or similar mechanisms.
• Digital Signatures
• Message Authentication Codes
• Windows Vista Mandatory Integrity controls
• Repudiation
• Logging,Audit Trails,Digital Signatures
• To address repudiation threats, you should integrate mechanisms that allow your software to reliably verify the identity of users and log important actions that are performed on the system.These mechanisms include :
• Authentication
• Security Logging and Auditing
• Digital Signatures
• Public key cryptography with individual certificates
• Secure time stamps
• Information Disclosure
• Access Control,encryption,not storing secrets
• In order to prevent your software from disclosing sensitive information to unauthorized parties, you should use techniques to prevent information from being leaked and provide means to protect any data that is considered as valuable.These techniques include
• Encryption
• ACL's
• Exception Handling
• Denial of Service
• Graceful degradation,filtering,increase server resources
• To mitigate denial-of-service threats,your software design should integrate mechanisms for increasing its overall robustness such as :
• ACL's
• Filtering
• Quotas
• Authorization
• High Availability Design
• Elevation of Priviledge
• Access Control,Sandboxing
• To defend against elevation of privilege threats, your software should implement strong authorization techniques and handle exceptional conditions securely.These mechanisms include :
• Input Validation
• ACL's
• Permissions
• User groups and roles

Documenting Threats

• Documenting threats using a template.
• Theft of Auth Cookies Eavesdropping on Connection.
• Threat Target : Connection between browser and web server.
• Attack Techniques : Attacker uses sniffer to monitor traffic.
• Counter Measures : Use SSL/TLS to encrypt traffic.

Rating Threats

• Simple Model
• Risk=Probability * Damage Potential
• Scale 1
• 1-10
• 1 = Least Probable
• 10 = Most Probable
• Scale 2
• 1-10
• 1 = Least Damage
• 2 = Most Damage
• DREAD Model
• Greater granularization of threat potential
• Rates(prioritizes) each threat on scale of 1-15
• Developed and widely used by Microsoft

DREAD

• A methodology for risk rating.Each vulnerability is graded in all of the following categories.
• Damage Potential
• How great is the damage if vulnerability is exploited?
• Reproducability
• How easy it is to reproduce the attack?
• Exploitability
• How easy it is to launch an attack?
• Affected Users
• As a rough percentage, how many users are affected?
• Discoverability
• How easy it is to find the vulnerability?

We can also extend the above questions to meet your needs.For example you could add a question about potential reputation damage.

• Reputation
• How high are the stakes?
• Is there a risk to reputation which could lead to the loss of customer trust.
• Ratings
• Do not have to use a large scale because this makes it difficult to rate threats consistently alongside one another.You can use simple scheme such as High(1),Medium(2) and Low(3).
• High
• Damage Potential
• Attacker can retrieve extremely sensitive data and corrupt or destroy data.
• 10-Admin level
• Reproducibility
•  Works every time: does not require a timing window
• 10 - Web Browser
• Exploitability
• Bart Simpson could do it
• 10 - Novice Programmer
• Affected Users
• Master all Users
• 10 - All Users
• Discoverability
• Attacker can easily discover the vulnerability
• 10 - Published
• Medium
• Damage Potential
• Attacker can retrieve sensitive data but do little else
• 5 - Sensitive
• Reproducability
• Timing Dependent : Works only within a time window
• 5 - 3 steps
• Exploitability
• Attacker must be somewhat knowledgeable and skilled
• 5 - Can be Automated
• Affected Users
• Some Users
• 5 - some users
• Discovrability
• Attacker might discover the vulnerability
• 5 - Accessible to only few users
• Low
• Damage Potential
• Attacker can only retrieve data that has little or no potential for harm
• 0 - Looking Trivial
• Reproducability
• Rarely Works
• 0 - Very difficult to produce
• Exploitability
• Attachment be very knowledgeable and Skilled
• 0- Very Skilled
• Affected Users
• Few if any users
• 0 - Few Users
• Discoverability
• Attacker will have to dig to discover the vulnerability
• 0 - Unlikely

Examples

• Lets take the 2 threats described earlier
• Attacker obtains authentication credentials by monitoring the network.
• SQL commands injected into the network

Threat	D	R	E	A	D	Total	Rating
Attacker obtains authentication credentials by monitoring network.	3	3	2	2	2	12	High
SQL commands injected into application	3	3	3	3	2	14	High

Once you have obtained the risk rating you update the documented threats and add the discovered rating level, which is high for both the above threats.

Potential Threats to the email system

• Eavesdropping on mail
• Communication over internet is relatively easy to eavesdrop.Hence content of email is by no means confidential, critical information can be encrypted and in emailed attachment.
• Modifying email
• Interception of the communication allows an attacker to modify the email.Hence integrity of email is not guaranteed
• Spoofing email
• MTS blindly believes other MTS about who the sender of the email is.Hence no guarantee about the identity of the sender.
• Attacks against the mail servers
• Server is a "trusted software layer", making a limited functionality(sending/receiving mail) available to all clients.
• Email as an attack dispersion channel

Attack Formats

• Spam
• Marketer can send massive amounts of unsolicited email.
• Denial of Service Attacks
• Amount of storage space on mail server can be exhausted by receiving too many very big emails
• A mail server is slowed down by too many received emails.
• A client receives thousands of garbage emails and hence missing real email.
• Phishing
•  Email clients trust received spoofed email.
• Give out their private data accordingly
• Direct Reply Back
• Input in a direct fake website
• Email/ Malware
•  Email client is again a trusted software layer.
• Executable attachments make virus-spreading easy.

Possible Defenses

• Many other threats
• Privacy threat : Detecting when an email is read.
• Repudiation of Sending: Sender can deny having sent a message
• Repudiation of receiving : Receiver can deny having ever received a particular message.
• Eavesdropping and modification
• Can be countered by cryptographic techniques
• Spoofing
• Can be encountered by strong authentication protocols.
• Attacks against servers
• Can be countered by 
• Careful software coding.
• Clear access control model.
• Strong authentication.

However  email spam and phishing are hard to defend

• Phishing : There are always users without security knowledge.

Coding Phase

• Static Analysis
• Checking the source code for vulnerabilities.
• Tools for static scan
• checkMarx
• Veracode
• IBM AppScan
• Coverity
• Code Reviews
• Manual Code Reviews
• Security Best Practices
• Perform Input and Data validation
• Do not use insecure API's
• Fail securely
• Protect sensitive Data
• Manage Accounts Securely
• Implement proper authorization
• Follow secure auditing and Logging Procedures.

Security Testing

• Dynamic Analysis
• checking the application for vulnerabilities like SQL injection, XSS, CSRF etc.
• Tools used in dynamic scan
• HP Web Inspect
• OWASP ZAP
• IBM Appscan
• Application Fuzz Testing
• Penetration Testing
• Attack Surface Review

Deployment

• Server Configuration Review
• Disabled all default accounts?
• All unused services are disabled?
• Remove any hard coded passwords?
• Remove debugger hooks and other developer backdoors?
• Remove unnecessary files,paths and URL?
• Network Configuration Reviews
• Access to firewall is allowed from limited number of services.
• Routers and Switches are physically secured in a locked room within a secure facility
• Sensitive information such as passwords are not logged.
• Logged are periodically reviewed for suspicious activity.