Software Security is the utilization of procedures that evaluate, relieve, and shield Software frameworks from weaknesses. These methods guarantee that product proceeds to work and are protected from assaults. Creating secure Software includes considering security at each phase of the existence cycle. The significant objective is to recognize blemishes and imperfections as ahead of schedule as could be expected.
 |
| What is Software Security | Design Guidelines for Software Security |
Any software is the result of a confluence of people, processes and technology. In order for software to be secure, it must integrate relevant security processes. Software is secure, if it can guarantee certain operational features even when under malicious attack.
The guiding principles of software design security
can be condensed into an acronym, CIAA, which stands for:
v Confidentiality : Only authorized people
(or processes) can get access.
v Integrity : The presented data is
unaltered.
v Availability : The system and its data
are available even under adverse circumstances.
v Authenticity : Users are who they claim
to be.
Guidelines for Software Design Security
Software design is an important activity which
takes the requirements as an input, particularly the specification of a system
external behavior and deconstructs the system at possibly multiple levels into
components and their interactions. So, this step produces a description of the
software's internal structure which serves as the basis for software design
security, namely:
Ø Assurance of the software design's agreement with the specifications, typically the constraints regarding aspects and future evolution of the design.
Ø The rational for software
design decisions.
Ø The assurance case portion
related to software design, including argument and evidence for the design's
conformance to external behavior.
Ø The system's security
policy.
Ø Other relevant constraints.
Software design normally includes descriptions of the architecture, components, interfaces and other characteristics of a system or component. The design of secure software systems is critically dependent on understanding the security of single components. To attain best possible security, software design must follow certain principles and guidelines which are:
Ø It needs to be consistent
with a security policy.
Ø It needs to incorporate
the necessary security functionality.
Ø It needs to ensure that
specifications are met and the expected behavior is performed.
Ø It should employ a
separation of mechanisms, duties and privileges, including the principle of
least privilege.
Ø It should be able to
defend against outside attacks on the infrastructure and other components.
 |
| Software Security | Design Guidelines for Software Security |
The design of any software system is (among other things) an exercise in risk management, that tries to identify the things that can go wrong before they happen so that decision-makers are prepared if they happen. Software design security should follow a process-oriented approach, and ensure that the following activities are carried out.
Developing Use / Misuse cases:
Work with the architecture group to model use and misuse cases. While use cases depict the application's functionality, the inverse of the use cases (misuse cases) is modeled to understand and address the software design's security aspects. Create standard case templates that can always come in handy.
Performing software design security and architecture reviews:
The security architect
should get involved when the teams are engaged in the functional design and
architecture review of the software. To ease this process, try using the
checklist approach, since that works great and can be tracked. It is imperative
that the security architect works closely with the architecture team to
generate a software security plan which outlines its design in detail. The same
can be used as a check-and-balance guide during and after development.
Performing threat and risk modeling:
Threat modeling helps in determining the software's attack surface by examining its functionality for trust boundaries, entry points, data flows and exit points. If you are not familiar with the technique, use a threat modeling tool, because it always comes in handy for this exercise. The next activity that follows is risk modeling of software. It is accomplished by ranking the threats as they pertain to the organization's business objectives, compliance and regulatory requirements, and security exposures.
Generating test cases:
Try and use a combination of misuse cases, security design and architecture reviews, as well as threat and risk modeling, to generate a detailed security requirements document (technical details), which the developers can then use to write code. You can also use this plan to generate security test cases which should be executed during testing. Using a scenario-based security testing template. Which is effective in ensuring that the bare minimal security test cases are performed in every software development effort.
Guiding:
While performing the
above tasks, take some time to document them, because they can serve as
guidance or knowledge base. Document the best practices for secure architecture
and design, review checklists and design considerations, which can be used as
standard guidance tools organization-wide. These are living documents which get
updated with changes in technology. Good practice calls for documenting design
decisions made for security reasons, as well as ensuring traceability of design
items and decisions to requirements and code. Traceability is essential for the
assurance case.
Developers need to know software Design security
principles and how they are employed in design. They need to know ways to
recognize whether these principles were used in a design, and know how to
evaluate designs and proposed changes, including improvements. Finally, plan
for defense in depth (that is, layered defenses), and do not rely on silver
bullets, because they don't exist.
Post a Comment