This presentation provides insightful ideas and techniques to secure your software or system in a top-notch fashion.

1. Software Security Engineering

2. Prepared by:
Muhammad Asim

3. What we will learn today
• Security concepts
• Security risk management
• Design for security
• System survivability

4. What is Security
Engineering ?
Security engineering is concerned with how to develop and
maintain systems that can resist malicious attacks intended
to damage a computer-based system or its data.

5. Why Security Engineering?
• To make more dependable systems we need to secure over
systems from the threats from malicious and technically skilled
attackers as well as problems resulting from accidentals
mistakes in the development process.
• This has become a priority for businesses and individuals as
more and more criminals try to exploit networked systems for
illegal purposes.

6. Security Concepts

7. Security Concepts
• Assets
• Exposure
• Vulnerability
• Attack
• Threats
• Control

8. Security concerns
• Confidentiality
Ensuring that data is only accessible to authorized people and
organizations
• Integrity
Ensuring that external attacks cannot damage data and programs
• Availability
Ensuring that external attacks do not compromise the availability of
data and programs

9. Controls for security
• Controls that intend to ensure that the attacks are unsuccessful.
• Controls that are intended to detect and repel attacks.
• Controls that support from recovery problems.

10. Application/infrastructure
security
• Application security is a software engineering problem where the
system is designed to resist attacks.
• Infrastructure security is a systems management problem where the
purchased infrastructure is configured to resist attacks.

11. System layers where
security may be
compromised

12. System security management
• User and permission management
Adding and removing users from the system and setting up
appropriate permissions for users
• Software deployment and maintenance
Installing application software and middleware and configuring
these systems so that vulnerabilities are avoided.
• Attack monitoring, detection and recovery
Monitoring the system for unauthorized access, design strategies
for resisting attacks and develop backup and recovery strategies.

13. Security Risk Management

14. Security risk management
• Risk management is concerned with assessing the possible losses
that might ensue from attacks on the system and balancing these
losses against the costs of security procedures that may reduce
these losses.

15. Note:
Risk management is a business issue rather than a technical
issue, so software engineers should not decide what controls
should be included in a system. It is up to senior management to
decide whether or not to accept the cost of security or to accept
the exposure that results from the lack of security procedures.

16. Risk management involves
• Preliminary risk assessment
• Life cycle risk assessment
• Operational risk assessment

17. Preliminary risk assessment
• In preliminary risk assessment security requirements for the whole
system, not just the software.
• At this stage, decisions on the detailed system requirements, the
system design or the implementation technology have not been
made.

18. Preliminary risk assessment

19. Misuse cases
Misuse cases are instances of threats to a system.
•Interception threats
Attacker gains access to an asset
•Interruption threats
Attacker makes part of a system unavailable
•Modification threats
A system asset are modified
•Fabrication threats
False information is added to a system

20. Asset analysis
Asset Value Exposure
The information system High. Required to support all
clinical consultations. Potentially
safety-critical.
High. Financial loss as clinics
may have to be canceled. Costs
of restoring system. Possible
patient harm if treatment cannot
be prescribed.
The patient database High. Required to support all
clinical consultations. Potentially
safety-critical.
High. Financial loss as clinics
may have to be cancelled. Costs
of restoring system. Possible
patient harm if treatment cannot
be prescribed.
An individual patient record Normally low although may be
high for specific high-profile
patients.
Low direct losses but possible
loss of reputation.

21. Threat and control analysis
Threat Probability Control Feasibility
Unauthorized user
gains access as system
manager and makes
system unavailable
Low Only allow system
management from
specific locations that
are physically secure.
Low cost of
implementation but care
must be taken with key
distribution and to
ensure that keys are
available in the event of
an emergency.
Unauthorized user
gains access as system
user and accesses
confidential information
High Require all users to
authenticate
themselves using a
biometric mechanism.
Log all changes to
patient information to
track system usage.
Technically feasible but
high-cost solution.
Possible user
resistance.
Simple and transparent
to implement and also
supports recovery.

22. Security requirements
• Patient information must be downloaded at the start of a clinic
session to a secure area on the system client that is used by clinical
staff.
• Patient information must not be maintained on system clients after a
clinic session has finished.
• A log on a separate computer from the database server must be
maintained of all changes made to the system database.

23. Life cycle risk assessment
• Risk assessment while the system is being developed and after
it has been deployed
• More information is available - system platform, middleware and
the system architecture and data organization.
• Vulnerabilities that arise from design choices may therefore be
identified.

24. Vulnerabilities associated with
technology choices

25. Security requirements
• A password checker shall be made available and shall be run daily.
Weak passwords shall be reported to system administrators.
• Access to the system shall only be allowed by approved client
computers.
• All client computers shall have a single, approved web browser
installed by system administrators.

26. Operational risk assessment
• Environment characteristics can lead to
new system risks
• Risk of interruption means that logged
in computers are left unattended.

27. Design for Security

28. Design for security
• Architectural design
how do architectural design decisions affect the security of a
system?
• Good practice
what is accepted good practice when designing secure systems?
• Design for deployment
what support should be designed into a system to avoid the
introduction of vulnerabilities when a system is deployed for use?

29. Architectural design
• Two fundamental issues have to be considered when designing an
architecture for security.
• Protection
How should the system be organized so that critical assets can
be protected against external attack?
• Distribution
How should system assets be distributed so that the effects of
a successful attack are minimized?
• These are potentially conflicting
If assets are distributed, then they are more expensive to protect. If
assets are protected, then usability and performance
requirements may be compromised.

30. Protection – defense in depth

31. Layered protection model
• Platform-level protection
Top-level controls on the platform on which a system
runs.
• Application-level protection
Specific protection mechanisms built into the
application itself e.g. additional password protection.
• Record-level protection
Protection that is invoked when access to specific
information is requested

32. A layered protection
architecture

33. Distribute assets to reduce
losses

34. Distributed assets
• Distributing assets means that attacks on one system do not
necessarily lead to complete loss of system service
• Each platform has separate protection features and may be different
from other platforms so that they do not share a common
vulnerability

35. Distributed assets in an equity
trading system

36. Guideline for Security
Design
• Base security decisions on an explicit security policy
• Avoid a single point of failure
• Fail securely
• Balance security and usability
• Be aware of the possibility of social engineering
• Use redundancy and diversity to reduce risk
• Validate all inputs
• Compartmentalize your assets
• Design for deployment
• Design for recoverability

37. System Survivability

38. System Survivability
dependency
System survivability depends upon three factors
•Resistance
– avoiding problems by building capabilities into the system to repel attacks.
•Recognition
– detecting problems by building capabilities into the system to detect attacks and
failures and assess the resultant damage.
•Recovery
– tolerating problems by building capabilities into the system to deliver essential
services whilst under attack and to recover full functionality after an attack.

39. System Survivability analysis
Four stage process:
•System Understanding
•Critical services identification
•Attack simulation
•Survivability analysis

40. System Survivability analysis

41. Thank you !!!