First Principle of Software Engineering

Aristotle’s account of a first principle (in one sense) as “the first basis from which a thing is known” (Met. 1013a14–15) – Wikipedia

Thinking about the first principle of software engineering as the essence of the practice helps us understand how to align our expectations and choose strategies that are appropriate. It also helps us think of Software Engineering as a discrete discipline that requires skill and experience. It is not a shallow practice producing lines of code in a vacuum. It is more like producing well thought out lines of code to complete a valuable idea for solving a problem. This value depends on various attributes to be fit to be a part of or a whole solution. Further, value in software is often not a single point in time. Value multiplies over time. Short-sighted additions die on the vine and require twice the work to revive later.

Therefore, the essence of Software Engineering is to:

Resiliently Add Computing Value

It is easy to see that disposable code does play a role in the IT landscape. However, it has less value to a Software Engineer. The first principle indicates a goal of accumulating value in a solution or system through modification, preferably enhancement and not repair. Although, if you are inheriting a system that has more value in the idea than execution, you are forced to start at a disadvantage.

Baseline First Principle Strategies

After stripping it down to its essence, we can identify the most fundamental Software Engineering strategies. These are Resilience, Completeness, Transparency and Automation.

Let us expand on these concepts and explain how they may relate to security concerns.

Resilience

Resilience stands out as an obvious first choice given it is found in the first strategy statement. Resilience describes an application’s ability to keep running predictably under unfavorable circumstances and load. It also describes how software should fail gracefully without corrupting or exposing data or causing any other damage. As well as it indicates recovery from such failure.

You may recognize that Resilience as a strategy for Availability. It is also how we deal with injection, timing attacks, enumeration and various other attacks that leverage glitching. We will cover various tactics to address Resilience, like Defensive Coding and Dependency Management.

Completeness

Another baseline strategy supporting the first principle is Completeness. This describes addressing implicit requirements in a way that creates a cohesive solution. Each context brings with it certain attributes that must be addressed. Sometimes this involves complementary solutions as in the case of Authorization and Authentication to support multi-user contexts. Further, authorization would completely cover sensitive data without “insecure direct object references”.

Completeness means we maintain confidentiality and integrity. We will cover aspects of Completeness with the sections on Auth, Square, Requirements Mastering and Testing.

Transparency

Transparency is something that has become particularly important in development processes, but it is invaluable at the code level. There are certain situations that require being specific and explicit. Rarely, if ever, is there value in obscurity, especially when speaking of security. Further, a transparent system is a supportable system.

Transparency describes the need to enforce non-repudiation. It can be used to guide what we need to log. Transparency helps us measure how resilient the system is.

Automation

In a sense, automation is the most basic of computing principles. It is why computing is valuable. It is also important to modern process management. Automation explains the need to document and version control processes. For many, automation enables the “always be practicing” philosophy that is a precursor to Continuous Integration and Continuous Deployment. Further automation limits a process’s exposure to failures due to differences between executions.

Ultimately, Automation is a first-level strategy shared directly with security. The ability to repeat a process with highly controlled change between executions is nearly priceless if the process is transparent enough that failures can be accounted for in subsequent execution. This allows an iterative approach to complete problem domain coverage. Resilience can also be enhanced as new and unforeseen circumstances emerge. This focuses effort on progress without wasting it on activities that would otherwise need repeating.

Conclusion

I encourage you to use the First Principle to develop a organizational mindset that embraces these stratigies at their most fundamental level.

In a time when we are on the cusp of a code explosion in much the same way we had an explosion of networks with the popularity of cloud, it is important to establish this complete Software Engineering mindset. Once such an understanding is positioned, we can build strategies for quality secure solutions to distinguish ourselves from the deluge of low brow software that is knocking at our door.

Starting an Application Security Program

Sometimes the hardest step to take is the first. If you are facing a non-existent Applicaiton Security (AppSec) Program, or one that needs a reboot, here are some suggestions on how/where to start.

Beginners Advantage

The first mistake that can be made when there is no formal AppSec Program is to fail to take advantage of the existing situation. If you have no program, the Development Team are the only ones responsible for security. Long-standing programs struggle to establish this because they have long since taken Security out of the hands of the Development Team.

The reality of an AppSec Program is that its primary function will always be Assurance. Rarely, if ever, have I observed an AppSec Engineer directly contribute to the application lifecycle in any other way. Many do not even have Software Engineering experience as they are usually plucked from Infrastructure Security. This is corroborated by the many job listings for AppSec, which list Penetration Testing skills and certifications as requirements.

Because this background is common, development teams are rarely recognized for established security practices. Any existing Development Team will be performing activities devoted to fixing flaws and reacting to incidence as well as many other activities essential to the success of an AppSec Program.

Assertion

By taking advantage of this initial strength in Assurance, an AppSec program can assert itself as an aid to achieve higher standards. The focus of those higher standards is obviously Security, but also with an understanding that broader attributes of quality and maintainability are directly related to repeatable security enhancement. There is an obligatory relationship between Security and Quality, where Application Security Programs can never productively be more sophisticated than Quality Assurance (QA) and Control (QC).

Based on this approach, the AppSec Team should identify and acknowledge areas where the Development Team are doing well. Then they should work together to identify ways in which small changes can be made to emphasize security or to bring existing practices into full compliance with security definitions.

Footprinting

Security frameworks can be highly valuable in the initial stages of an AppSec program. These come with tools for framing context, setting goals and tracking progress. Frameworks are not a one-size-fits-all solution. Development teams will differ wildly. Learning from implementing a security framework will forever influence them, good and bad. So be careful about forcing a framework into a situation where it does not fit.

One personal favorite is OWASP SAMM. It establishes a vocabulary and definition system that can be socialized among development teams. It also has a questionnaire that can be used to footprint the existing development process and then be used to track progress. Early on SAMM can be used to identify practices that partly match the purpose defined and signify low investment gains toward maturing the Security Program.

Establishing Roots

Certain domains of OWASP SAMM require heightened interaction between AppSec and Dev teams. Those are the domains of Design and Verification. Verification is a SAMM domain that can be initiated and driven though automated tooling until the output reaches a level where more manual Verification processes can be implemented to find less-common issues.

To quickly establish a valuable feedback flow from Verification, implement automated Application Security Testing tools. Then create a process for adding Development work items from these tools. This should closely model how flaws from QA flow. It may be necessary to enhance the QA process or even the development process to accommodate multiple sources.

It is good to note that up to this point progress reporting to upper management should consist entirely of the progress of Application Security implementation. It should have nothing to do with vulnerabilities or flaws until the Development Team has had several cycles to get acquainted with the information and how to address these sorts of issues. There should also be an additional timebox to work through some initial issues. This additional buffer should be worked into the plan early. This places the AppSec Team in an adversarial posture toward vulnerabilities and not the Development Team.

Breaking Ground

Once the Verification process has started it is time to establish elements from the SAMM Design domain to direct the implementation away from common pitfalls and major catastrophe. This may be where establishing the AppSec Program gets difficult, especially if there is a lack of development background on the Security Team. This is a much simpler task when the previous steps have been performed in concert with the Development Team. It may be that when done well, the Development Team will seek out the AppSec Team with the desire to integrate security methodologies in the Requirements, Architecture and Design phases of development.

At this point the team can simply start by asking questions to introduce security to requirements gathering or backlog grooming as well as architecture. It is also useful to introduce Threat Modeling via the Four Question Framework:

• What are we working on?
• What can go wrong?
• What are we going to do about it?
• Did we do a good job?

Growth

This is the point where meaningful conversations can happen about the AppSec Program’s maturity. Next, work on the SAMM domains of Operations and Governance to bolster a holistic Application Security Program. Start scoring using the OWASP SAMM questionnaire on a regular interval to track the program’s progress.

I hope this inspires new Application Security Programs to progress down a path of logical development with an eye to embedded cooperation with Development. There are times when working in Security can seem hopeless unless we look ahead to maturing the methodology. It is not about “Shifting Left” to force reinvented processes on development. Never forget that Software Development was established long before someone decided to excavate security concerns and assign them to AppSec. Reintegrating them is the best way to gain quick traction and lasting productivity.