software security engineering guruprasad ayyaswamy asu id # 993993506

Software Security Engineering

Guruprasad Ayyaswamy

ASU Id # 993993506

Discussion OverviewIntroductionGlimpse of Software EngineeringGlimpse of Security EngineeringSoftware Security Engineering (Waterfall based model)Conclusion

Software systems Objectives: Engineered with reliable protection

mechanisms. Deliver the expected value of the software

to their customers

Importance of Secured Systems:

In applications where the quality of service

depends on data confidentiality, data integrity,

and protection against denial-of-service attack,

the need for secure networks is evident.

Objectives

Software Engg Security Engg Software Engineering

Usability

Performance

Timely Completion

Reliability

Flexibility

customized access

control and authentication

based on the privilege levels

of users,

traceability and detection,

accountability,

non-repudiation,

privacy,

confidentiality, and integrity

Objectives (contd…)

Current Software Engineering processes do not

provide enough support to achieve security

goals.

Unification of the process models of Software

engineering and Security Engineering is

required.

Software Security Engineering objectives are to

design a software system that meets both

security objectives and application objectives

Principal Objective of SSE

Software Security engineering is a practice to

address software security issues in a systematic

manner.

Security issues must be addressed in all the

stages of software system development and the

maintenance life cycle ,such as: Requirements, specifications,

Design, Testing,

Operation, and Maintenance.

Unification of Process Models (SE &SECE) Advantages:

It removes the unnecessary differences that obscure the

fundamental principles of the development and

maintenance of secure software systems. System designers to employ the techniques and tools of

software engineering and security engineering. Help to incorporate the advancement of the features of

one engineering process into the other

SSE based on Waterfall process model

The waterfall model is a sequential software

development model (a process for the creation of software)

in which development is seen as flowing steadily

downwards (like a waterfall) through the phases of

requirements analysis, design, implementation, testing

(validation), integration, and maintenance.

SSE based on waterfall model

The rationale for choosing is that it contains most of

the fundamental steps present in all other software Process models that currently exist in the literature.

Process that incorporates security issues in all the

steps of software life cycle will work fine in other software process models. For example, the incremental modelis widely used in industry with a view to reducing the delay in delivering software products. It consists of severalincrements or builds, where each increment follows thewaterfall model.

Glimpse of Software Engineering

Definition: In the IEEE Standard Glossary of Software

Engineering Terminology (IEEE Std. 610.12-), software engineering is defined as follows: “(1) Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering tosoftware.

Concerned with all aspects of software production

from system specification to maintenance of the system after it has been deployed


SE is a subset of system engineering System Engineering focus on Software and Hardware SE only focus on software aspects.

The following are different software development cycle

models, such as waterfall, incremental, spiral, and rapid

Prototyping.

Waterfall model is the most widely used and discussed. The steps involved in most models are requirement

gathering and analysis, software architecture,

implementation, and testing.


Stakeholders: analysts, designers, programmers, testers, maintenance

personnel, project managers, end end-users or customers

In summary, low cost, high quality, and rapid software development are the key goals of software engineering.

security issues have not yet been incorporated or addressed in the software development processes.

Glimpse of Security Engineering

Definition:Security engineering is a discipline for “building systems

to remain dependable in the face of malice, error, or

mischance,” where the discipline “emphasizes the tools,

processes, and methods needed to design, implement, and

test complete systems, and to adapt existing systems as

their environment evolves” It deals with a number of issues such as intrusion protection

and detection. It ensures that a system is secure from both software and

hardware perspectives.

The threats to security are identified as interception,

interruption, modification, and fabrication of data. The threats are usually defined based on some security

policy of the organization. Violations of any security policy are combated using

different security mechanisms such as encryption, authentication, authorization, and auditing.

It addresses the complete life cycle for building a secure system such as, requirements specification and analysis, design, development, integration, operation, maintenance and re-engineering


It requires expertise in interdisciplinary areas to deliver a secure system.

computer system management and development, software and hardware security, networking and cryptography, applied psychology, organizational

management, and law.


Waterfall based software security engineering process model Having discussed both software engineering and security

engineering, it is important to note that “while software engineering is about ensuring that certain things happen, security is about ensuring that they don’t”.

The major steps of the proposed model are: system engineering, requirements specification, software design, program implementation, and system operation.

System Engineering

The end-product of the software security engineering process is software.

The system engineering phase of the software security

engineering process identifies the software aspects of the system to be developed.

This phase focuses equally on both functionalities and security issues of the software system based on the users’ or stakeholders’ needs.

Both software engineers and security engineers work closely in this phase.

System Engineering

Requirement Specification

Software requirements are usually referred to as functional requirements that specify the behavior of the system; that is, the relationship between inputs and outputs.

A nonfunctional software requirement describes not what the software will perform, but rather how effectively the software will perform. For example, usability, reliability, interoperability, scalability, and security are some of the nonfunctional properties of software systems.

Security is usually incorporated in the system development in a subjective manner

There are some inherent difficulties associated with security requirements specification: Security requirements are often difficult to specify in the

early phases of the software development life cycle, since the software model tends to be very abstract and is usually presented in an informal manner.

In addition, security risks are difficult to estimate, and as the software development progresses, developers receive new information about the system security

So it is often difficult to specify security measures and integrate them into the actual system from the very beginning of the software development process.

In most cases, security requirements are not addressed at all during the early design phases.


In the software security engineering process, both security and functional requirements are specified in the requirements specification phase (see Figure 3).

The weaknesses of software-controlled systems with respect to the software security can be alleviated by specifying functional and security requirements using formal methods, and then by reconciling and integrating the two sets of formal specifications at an abstract level.

Scenarios: A technique for elicitation, analysis, and documentation

of software requirements.


A scenario is a sequence of related events or actions represents meaningful high level operation of a system.

In SSE process two types of scenarios: usage scenarios and attack scenarios.

The attack scenarios can incorporate expert knowledge on security, and they may be ranked based on their importance in the system being implemented.

For example, defending against a denial-of-service attack in a client machine may not be as important as it is in a server machine.


A scenario can be represented in various forms: To avoid inconsistency and redundancy, it is highly recommended that both usage scenarios and attack scenarios be defined using the same specification language.

Software specification languages can be translated to attack languages and vice versa.

Abstract State Machine Language (ASML) is automatically transformed to a high level attack specification language called State Transition analysis Technique Language (STATL), which can pre programmed and loaded into an intrusion detection system at runtime.


Software Design

Functional and security issues are interconnected to where the software components are deployed and how they communicate with each other. For example, the architecture and its protection mechanisms depend on whether the system will operate as a centralized or a distributed one.

In the software security engineering process, a software system should be designed based on the following two principles: compositional software architecture and scenario based software architecture.

Flexible software architectures are desirable to adapt the design changes in those situations.

A compositional software architecture is one in which the changes required for the whole system can be obtained by applying the changes to its components.

This is only possible if the principle of compositionality and the security concerns were taken into consideration in defining each software component in the software design phase.

Software Design

C is composed of the components C1, C2,..., and Cn by employing a set of composition operators.

Let the security requirements of C1, C2,..., and Cn be S1, S2,..., and Sn respectively.

A compositional design implies that the whole system C satisfies the complete specification S if each component Ci satisfies Si for i= 1,...,n.

Software Design

Scenarios: Scenarios are very useful to compare design alternatives

and to understand a legacy system by analyzing the system responses in the context of different environments.

The potential attacks to a system can be specified using attack scenarios, which initially may be abstract, and are refined as the design evolves by considering all security-relevant issues.

Software Design

Implementation

During programming, we should ensure that potential security flaws, identified as security requirements and avoided in the earlier phases of the software security engineering process, are not reintroduced in the source code.

Security engineers should participate in coding Propose to follow the principle of code refactoring

successfully employed in the context of extreme programming

The software should be tested for both functional and security requirements.

System Operation

Conclusion

Systematic integration and organization into a process that will lead to secure software systems.

It is very difficult to achieve two sets of desired objectives while they “trade off against one another”. For example: an application software may require root-level access privileges in a system to run the application, while in some cases it may mean weakening the security of the target system. We believe that the trade-off among these goals is very application-dependent.

References

http://en.wikipedia.org/wiki/Waterfall_model http://en.wikipedia.org/wiki/Denial-of-service_attack

Anderson, R. (2001). Security engineering - A guide to building dependable distributed

system. New York: John Wiley & Sons. Barnett, M., Grieskamp, W., Gurevich, Y., Schulte, W.,

Tillman, T., & Veanes, M. (2003, May). Scenario-oriented modeling in AsmL and its

instrumentation for testing. In Proceedings of the 2nd International Workshop on

Scenarios and State Machines:

Beck, K. (1999). eXtreme programming explained: Embrace change. Reading, MA:

Addison Wesley. Boehm, B. W. (1988). A spiral model of software development and enhancement. IEEE Computer, 21(5), 61-72.

Models. Algorithms, and Tools, Portland, OR (pp. 8-14). Basin, D., Doser, J., & Lodderstedt, T. (2003). Model-

driven security for process-oriented systems. In Proceedings of the 8thACM symposium on

Access Control Models and Technologies, Como, Italy (pp. 100-109).

Thank You !