Why do good requirements go bad? What can be done to prevent things from going bad?
Answer the question with a short paragraph, with a minimum of 300 words. Count the words only in the body of your response, not the references. APA formatting but do not include a title page, abstract or table of contents. Body and references only in your post.
A minimum of two references are required. One reference for the book is acceptable but multiple references are allowed. There should be multiple citations within the body of the paper. Note that an in-text citation includes author’s name, year of publication and the page number where the paraphrased material is located.
-
ISOL536Chapter12Presentation.pptx
University of the Cumberlands School of Computer & Information Sciences
ISOL-536 – Security Architecture & Design
Chapter 12: Patterns and Governance Deliver Economies of Scale
Chapter 12: Patterns and Governance Deliver Economies of Scale
12.1 Expressing Security Requirements
12.1.1 Expressing Security Requirements to Enable
12.1.2 Who Consumes Requirements?
12.1.3 Getting Security Requirements Implemented
12.1.4 Why Do Good Requirements Go Bad?
12.2 Some Thoughts on Governance
Summary
Chapter 12: Patterns and Governance Deliver Economies of Scale
A well-known result from rigid, standardized processes and heavy governance of those processes is a slowdown in delivery. When due diligence (i.e., security architects) resources are highly constrained, and there exist rigid processes that require those shared resources to assess everything, due diligence will become a severe bottleneck rather quickly. On the face of it and simplistically, it may seem intuitive to enact a “law and order” and/or “command and control” process. Make everyone behave properly. But anyone who’s read the legendary book, The Mythical Man-Month: Essays on Software Engineering, by Frederick P. Brooks, Jr.,1 and similar studies and essays, knows that the more administration and bureaucracy an organization installs, the less work actually gets done.
Chapter 12: Patterns and Governance Deliver Economies of Scale – Cont.
One classic problem is how to deal with systems that will be exposed to the public Internet. We know, without a doubt, that the public Internet is hostile and that hosts on the public Internet will be attacked. To counter this omnipresent attack level, there are typical solutions:
Firewall allowing traffic only to the designated public interface that will be exposed
Bastion, HTTP/S terminating host (or the equivalent, such as a load balancer or virtual IP manager)
Access restriction to and protection of management and administrative interfaces
Network and protocol restrictions between traffic terminators and application logic, between application logic and storage or databases. That is, multiple tiers and trust levels
Security configuration, hardening, patching of known vulnerabilities, and similar
Authentication between layers of the automated processes and between trust levels
Restriction to and protection of the networking equipment.
Chapter 12: Patterns and Governance Deliver Economies of Scale – Cont.
Management of administrative access to the systems that may be exposed to potentially hostile traffic is a fairly well documented body of practice. For those example architectures in which rigorous management was among the security requirements, in this book I have consistently cited NIST 800–53 as a reference to the body of practices that would fulfill this requirement. The citation is not to suggest that an organization shouldn’t create its own standards. Nor do I mean to suggest that the NIST standard is the one and only best standard. It is simply well known and relatively widely accessible. At this point in information security practice, I see no need to regurgitate these “table stakes” requirements. There isn’t much mystery or contention about what robust system management entails.
12.1 Expressing Security Requirements
Applications rarely have clear security requirements over and above the vague injunction to follow all corporate security policies. The architect is left groping in the dark when confronted with the question, “Does this product support the context in which security appears within my application?”
Indeed, there is a significant conflict between empowering intelligent, skilled people to be creative and innovative against the necessity to make sure that certain steps are followed and, particularly, that the important, high-priority security requirements get addressed. I believe that it is impossible to Simultaneously empower people to think for themselves and also order the same people to do as they are told. When people think for themselves inevitably they are going to form their own opinions. Even more so, highly capable people’s divergent opinions might just be correct.
12.1.1 Expressing Security Requirements to Enable
One of the key skills that can help is writing requirements at the correct level at which the requirements will be consumed. This is often a difficulty for engineers who are used to expressing a technical matter in as much detail as possible. For any but an inexperienced or unskilled implementer, this will be a mistake. There has to be enough specificity that the security requirement can be implemented somehow, that the goal of the requirement can be met. But generally, a requirement shouldn’t be written such that it hamstrings the implementers to exactly one particular and narrow implementation.
12.1.2 Who Consumes Requirements?
The maxim for getting requirements to the right level of specificity is, “just enough to deliver an implementation that will meet the security goals.” In this example, the security architect is not really concerned so much with how the restrictions are implemented but rather that it will be difficult for an attacker to use the terminating network (DMZ) as a beachhead to attack the application server. The security architect is interested in preventing a loss of control of the bastion network (for whatever reason) to cause a loss of the entire environment, starting with the application server. That means traffic to the application server must be restricted to only those systems that should be communicating with it, with traffic originating from termination to application server, never the other way around. That’s the goal. Any networking method employed to achieve the goal is sufficient.
Consider a requirement that specified MD5 at a time when it was still considered sufficient protection. Not only would every system that had implemented MD5 be subject to change, but all requirements specifying MD5 would suddenly become obsolete. What if MD5 were specifically called out in a corporate standard or, even worse, in a policy? In large organizations, policies are only rarely changed, and only with approval at a fairly high level in the organization, often with several stakeholder organizations (for instance, a Legal Department). In response to the loss of a particular cryptography algorithm that has been specified in a policy, changing the policy and all the requirements to meet that policy becomes quite an expensive proposition.
12.1.2 Who Consumes Requirements? – Cont.
When requirements cannot be met, for whatever reason, a risk analysis will help decision makers to prioritize effectively. It’s useful to remember that different stakeholders to a risk decision may need to understand the impacts expressed in terms of each stakeholder’s risks. We covered this topic somewhat in the chapter on risk (Chapter 4). Although there are many places in the security cycle where risk may need to be calculated and expressed, the prioritization of security requirements against resource constraints, budgets, and delivery schedules remains one of the most common. This is typically a place where the security architect, who has a fundamental understanding of risk and organizational risk tolerance, can offer significant value. When decision makers have built trust that the security function has a method for rating risk in a consistent and fair manner, they may come to depend upon those risk ratings in their decision-making process.
12.1.3 Getting Security Requirements Implemented
In today’s fast-paced, often “agile” software development, how can the secure design be implemented? In my experience, tossing requirements, architectures, and designs “over the wall” and into the creative, dynamic pit of Agile development is a sure road to failure.
Three things, not mutually exclusive by any means, are likely to occur:
Artifacts injected into an Agile methodology from the outside will be ignored because the documents appear to be irrelevant.
Developments, learnings, and changes during development will cause elements to change, even for assumptions to get invalidated, causing security elements to change drastically or not get accomplished at all.
If the Agile team members attempt to adhere strictly to artifacts brought in from the outside and not directly generated by the Agile process, this blind adherence will cause team velocity and creativity to fall, even to stagnate.
10
12.1.3 Getting Security Requirements Implemented – Cont.
It’s important that the security assessor has good reasons for each requirement. Data on attack levels, types of attacks, well-known compromises, and the like bolster the reasoning for the requirement. At one job, I learned that our web interfaces received seven million attacks each day. When I had to drive a web security requirement, mentioning that statistic often removed resistance, once people understood that attack was reasonably certain.
A big mistake is to issue a security requirement that forces another group to interrupt the way it works, the flow that has been carefully crafted over time. In the above example, every solution proposed required the IT team to lose some of their efficiency.
11
12.1.4 Why Do Good Requirements Go Bad?
One or more requirements may not be implementable as written, possibly not buildable at all. There are many reasons why requirements don’t actually get built that have nothing to do with how well the requirements are written. For instance, there may be changes in the business context that cause schedule, budget, or resource shifts. Or assumptions that a design has been built upon may turn out to be incorrect, invalidating requirements based upon those design assumptions.
12
12.2 Some Thoughts on Governance
Governance is introduced into an SDL or system delivery process not to ensure that everything is perfect, but so that these hard decisions don’t slip under the radar and are not made for the convenience of those charged with on time, under-budget delivery. These people have a built-in conflict of interest and may not have the security and sufficient computer risk background to effectively make these sorts of decisions.
In order to keep velocity high, the governance check had to be very, very lightweight. Eventually, IT people responsible for deployment were given the project list so that the security engagement check didn’t even require a security person (junior or not). It was simply a part of the woodwork. Governance of this nature works best, I think, when it is almost invisible, except for those projects that are out-of-process. And in the certain knowledge that there is a check, both for web vulnerabilities and engagement, only the very brave and/or the foolhardy attempted an end run outside of the process. We let everyone know that these checks were in place.
13
Chapter 12: Summary
Where there is resistance, having concrete examples helps stakeholders understand the reasoning that gives birth to each security requirement. Sometimes, a single, pithy statistic or particular attack example will help others jump on the security bandwagon. For those instances in which there is outright resistance, identifying what is being protected or some other solvable pain point can turn enemies into allies.
No matter what happens, in complex, highly dynamic organizations there must be some governance that security requirements are being fulfilled. This is necessary even when there is a great deal of security buy-in, because there always seems to be at least one clever person who will attempt shortcuts to delivery. There has to be a method that catches these attempts even when they are rare. Otherwise, the defense of other systems may be impacted; there’s a due diligence responsibility to ensure that requirements are met or risks raised to decision makers.
Chapter 12: Summary
END
image1.emf
image2.emf
Why do good requirements go bad? What can be done to prevent things from going bad?
Introduction
The process of writing good requirements is not an easy task. In fact, it can be difficult if you don’t have experience with the topic. But there are ways to make sure your team is able to write good requirements so that there aren’t misunderstandings later on down the road.
A requirement is bad when it has to change very often.
A requirement is bad when it has to change very often. For example, if you have a requirement that says “the user should be able to add an item to the shopping cart”, but then changes to say “the user should be able to remove an item from their shopping cart”, it’s going to be difficult for developers and designers alike because they won’t know what the new requirements are. This can lead them into making mistakes when building out their system or app, which increases time spent on fixing bugs in your application (and potentially losing money).
The more often requirements change, the less likely it is that developers can accurately estimate how much work they will take on each new iteration of said system/app (e.g., if I’m working on an online store and my boss tells me we need our checkout process improved so we don’t get charged back fees).
When requirements aren’t ready in time, they go bad because most of the developers’ time is taken up with planning and other development activities.
Developers need to know what they are building before they start building it. This means that requirements need to be written down, reviewed by others, and managed through their life cycle. The longer you wait for the first review of your requirements document, the greater chance there will be for problems with them being found or corrected later on down the line.
One of the things that makes people mad is the need to constantly change requirements.
This can be frustrating for everyone involved, especially if it’s something that needs to be done on a regular basis. The best way to prevent this from happening is by making sure you’re communicating with your stakeholders clearly about what their expectations are and how you will meet them. If a stakeholder isn’t clear about what they want or how they want it delivered, then there’s no way for them or anyone else involved in your project (including yourself) not only know where they stand but also know when they’ve reached an agreement on expectations between all parties involved in developing software products or implementing systems/services based off those products’ designs
Requirements need to be written in a language everyone understands and in a way that can be translated into actionable tasks.
The first step in writing effective requirements is to use a common language that everyone understands. This is important because it allows you and your team members to communicate effectively, which will help you avoid misunderstandings and problems later on.
Once you have established a common language, then it’s time for us write down the requirements in that language. In other words, we should translate our ideas into actionable tasks so they can be easily understood by everyone involved in the project at all times during its development cycle (and beyond).
If you take care not to have changes happen too often, not having requirements ready on time, and avoiding scope creep, your team will be able to focus on writing good code.
-
Avoid scope creep. Scope creep is when the project gets bigger than you originally thought it would be, and your team has to work longer hours to get it finished. This is a common problem in agile teams who have difficulty keeping up with their milestones and deadlines, but it can happen even without these kinds of pressures.
-
Make sure that your team doesn’t get into a situation where changes happen too often. The best way for this not to happen is by making sure all the requirements are written down before starting any development activities (like writing code), so that if something needs changing later on down the road (and there’s no time yet), then you’ll already know what needs changing and how much work will go into fixing said issue before moving forward again with other tasks such as adding new features based off feedback provided by clients/users after testing early versions ourselves first hand rather than relying solely upon our own experience which might not be accurate enough sometimes due simply because how different each person’s experiences might differ depending upon each person’s background knowledge base base set forth over years spent doing similar type work prior experience gained during those years working at various companies previous employment history thus making comparisons between projects impossible without some sort best practices being followed consistently throughout entire project lifecycle from start until finish–this ensures nothing goes wrong later down line due lack communication between team members during planning phase leading up until deadline expiration date
Bad requirements can cause delays and misunderstandings, but there are ways to make sure they don’t happen
Bad requirements can cause delays and misunderstandings, but there are ways to make sure they don’t happen.
-
Write requirements in a language everyone understands. If you’re writing it down, it is easier for everyone to understand what the requirement means. This will help avoid misunderstandings during development and ensure that each person has an accurate understanding of what needs to be done in order for the project to succeed.
-
Make sure requirements are specific enough for development purposes. A good way to ensure this is by using user stories instead of written documents or emails as your primary source of communication between developers and stakeholders – because then there’s no room for misinterpretation when reading through large amounts of information quickly! This also helps keep things focused on one piece of functionality rather than spreading across multiple areas like “user interface design” or “business logic”.
Conclusion
There’s no magic bullet to prevent bad requirements from happening. However, it is possible to avoid them by following some guidelines and doing your homework before starting your project. For example, if you’re working on a new feature and you want to avoid scope creep, make sure everyone understands what is being asked for before beginning work on the design or implementation phase of the project.