1 Discussion – 2 Assignments

Disussion – Org Leadership and Decision Making  ( 2 pages)

Assignment 1 – Sec. Arc & Design – 2 Pages (> 600 Words)

Assignment 2 – Sec. Arc & Design – 600 Words  ( > 600 Words)

Assignment – Security Arch. & Design

Length: Minimum of 600 words

Due date: Thursday, December 10, 2020, 5:00pm EST

Briefly respond to all the following questions. Make sure to explain and backup your responses with facts and examples. This assignment should be in APA format and have to include at least two references.

At the end of your textbook on page 385, the author mentions several “encouraging security architecture developments”:

· The Open Group has created an Enterprise Security Architect certification. One of their first certified architects has subsequently created a few enterprise security reference architectures.

· The SANS Institute hosted three “What Works in Security Architecture” Summits.

· The IEEE initiated a Center for Secure Design. The Center published a “Top 10 Design Flaws” booklet.

· Adam Shostack published Threat Modeling: Designing for Security, and renown threat modeler, John Steven, has told me that he’s working on his threat modeling book.

· Anurag Agrawal of MyAppSecurity has been capturing well-known attack surfaces and their technical mitigations within his commercial threat modeling tool, “Threat Modeler.”

Choose 2 or 3 three items from the list above and provide an update to their development status. Make sure you provide some background on your selection and then provide the update of the development.

TextBook:

Title: Securing Systems

Subtitle: *PLEASE SEE BOOKSTORE LINK BELOW TO PURCHASE REQUIRED MATERIALS

ISBN: 9781482233971

Authors: Brook S. E. Schoenfield

Publisher: CRC Press

Publication Date: 2015-05-20

Discussion 1 – Org. Leadership & Decision Making

Reflection

This is a shortened week and therefore we are going to complete a reflection activity.

This discussion topic is to be reflective of the course material. Therefore, use your own words to respond to the following questions:

· What other topics would you have liked to have covered in this course?

· What reading did you find most interesting and why?

· How has this course changed your perspective or outlook moving forward?

· Any other topic of interest that you would like to add.

Please be sure to answer all the questions above in the initial post. You do not need to respond to posts.

Please be sure to engage ASAP as this forum will close on Tuesday 12/8 at 11:59pm EST.

TextBook:

Title: Organizational Leadership

ISBN: 9781529715460

Authors: John Bratton

Publisher: SAGE

Publication Date: 2020-02-10

Edition: 1st ED.

Assignment – Security Arch. & Design

Chapter #13 Building an Assessment Program

Length: Minimum of 600 words

Due date: Thursday, December 10, 2020, 5:00pm EST

Briefly respond to all the following questions. Make sure to explain and backup your responses with facts and examples. This assignment should be in APA format and have to include at least two references.

What does a peer review process look like? When does an assessment require peer review? Who should perform the peer review?

TextBook:

Title: Securing Systems

Subtitle: *PLEASE SEE BOOKSTORE LINK BELOW TO PURCHASE REQUIRED MATERIALS

ISBN: 9781482233971

Authors: Brook S. E. Schoenfield

Publisher: CRC Press

Publication Date: 2015-05-20

University of the Cumberlands
School of Computer & Information Sciences

ISOL-536 – Security Architecture & Design

Chapter 13: Building an Assessment Program

Dr. Sherri Brinson

Chapter 13: Building an Assessment Program
13.1 Building a Program
13.1.1 Senior Management’s Job
13.1.2 Bottom Up?
13.1.3 Use Peer Networks
13.2 Building a Team
13.2.1 Training
13.3 Documentation and Artifacts
13.4 Peer Review
13.5 Workload
13.6 Mistakes and Missteps
13.6.1 Not Everyone Should Become an Architect
13.6.2 Standards Can’t Be Applied Rigidly
13.6.3 One Size Does Not Fit All, Redux
13.6.4 Don’t Issue Edicts Unless Certain of Compliance
13.7 Measuring Success
13.7.1 Invitations Are Good!
13.7.2 Establish Baselines
13.8 Summary

Chapter 13: Building an Assessment Program
Security architecture calls for its own unique set of skill requirements in the IT architect.
For security architecture, the main ingredient will be the people and their skills to perform assessments and, ultimately, to craft and then drive security solutions. This comes down to the individuals and how to form your team.
Other things to consider.
Pre-architecture engagement fosters discovery and inclusion of required security features.
For new architectures, security engagement throughout the architecture cycle improves the integration of security requirements (vs. a one-time assessment).
For existing architectures, only architecture changes need to be assessed and threat modeled.
Any change in design of security-related portions or components necessitates a security design review.
Threat models are living documents; they change and, thus, must be kept in sync with changes in architecture and design.
Agile requires continuous engagement, since architecture and design are iterative and parallel processes (parallel to themselves, to implementation, and to testing).

13.1 Building a Program
A program cannot be built solely from top down, or completely from the bottom up, or only across a peer network, but rather all of these must come together in parallel, and also such that each vector of program development supports and strengthens the other dimensions. You will want to work on each of these dimensions at the same time. In my experience, there is no proper linear order, though it is true that, without senior management buy-in, very little can successfully take place.

13.1.1 Senior Management’s Job
Senior management communications can be made through their usual channels: newsletters, at organizational all-hands meetings, blog postings, through the organization’s hierarchy as “pass downs.” The key trick here is that this cannot be messaged just once through one, single media channel. Various formats and vectors combine for a more powerful delivery. No one on the system delivery teams should be surprised when a security architect shows up and asks to see the architecture. This message doesn’t have to be constant, but like all similar process-oriented communications, it will need to be repeated regularly.
But there’s more that senior management must do; they must stand behind the empowerment. Smart people will push back. Sometimes, the non-security people will have the best course for the company in mind. Remember, we all make mistakes; everyone is fallible.

13.1.2 Bottom Up?
In other words, when starting the program, plan for time for you and whoever is working with you to get out into the implementation teams and meet people, talk to them about security, find out what they think. More importantly, uncover fears about security, perhaps even poor experiences in the past. The latter is critically important. If you’re working with a pre-existing social debt, you need to understand what the history is, how the debt was accumulated, and what pain points originated with this debt.
By visiting teams and simply listening, one can learn a great deal. That’s almost always the first thing that I do when I join a new organization: I go on a “fact-finding mission.” Is there any history with security architecture? Have there been failures? And if so, why? What are people currently doing to achieve security objectives? Where do those security objectives originate? Who are the people who are engaged in security and what are their reasons for engagement? If I can, I try to identify those who are resistant, even potential enemies.

13.1.3 Use Peer Networks
If you are the director tasked with booting a security architecture and assessment program, your peers will be the network through which most of the day-to-day resourcing and priority issues are set. Although it is true that line management often takes care of these task-setting activities, if they run into trouble, it’s to your peer network that they will turn. It is through your peer network that you will need to influence priorities.
Just as important as middle management, senior technical leaders strongly influence the success or failure of a security architecture program. First, security architecture fits in as a portion of an overall architecture program and practice. That is, security is a specialty architecture practice that influences, shapes, and changes a system architecture within many organizations. Architects envision systems. Security architects envision the security of those systems. Although it is possible that both roles can be fulfilled by the same person, these are usually different people with separate but highly intersecting bodies of practice. It is a disaster if the architects and, especially, architecture leaders are not supportive of security architecture. In this case, nothing will get done.
You’ll want to make the timing of activities perfectly clear in your delivery processor project lifecycle. There isn’t much that can actually be done when the security assessment takes place a week, or worse, a day before going live. Rarely have I seen decision makers stop deployment, even in the face of the critical security misses discovered during late assessment.

13.1.3 Use Peer Networks – Cont.
Figure 13.1 Socializing the program across the organization.
Figure 13.1 is a whimsical visual representation of the social networks that need to be cultivated for program success. As shown in the figure, socialize and keep evangelizing and socializing; stay on message. Michele Guel says, “Say it three times, then find a different way to say it.” Prepare to perform years of repeated messaging. The effort to move a major public website’s authentication from HTTP to HTTPS was the work of three different security architects and took eight years. It’s important not to give up when a security requirement is the “right thing to do,” even in the face of significant resistance. Eventually, conditions will ripen such that that the “right thing” can happen.

13.2 Building a Team
My teams typically encompass many fairly divergent cultures, most of the world’s major religions, every stripe of political viewpoint, and any number of divergent value systems. All of this diversity makes for a rich stew out of which are born innovative approaches and synthetic solutions—if leadership can find value in a wide range of ideas and personality types and then demonstrate that encouragement. I believe that building a truly global, high-functioning team must start with the first person or two, usually those who will be “leaders” of the team. To paraphrase the famous saying, “Physician, heal thyself,” we might say, “Leader, lead thyself, first.”
Authentic leaders demonstrate a passion for their purpose, practice their values consistently,
and lead with their hearts as well as their heads. They establish long-term, meaningful
relationships and have the self-discipline to get results. They know who they are.

13.2.1 Training
How does an organization train people so that they can perform these difficult, architectural tasks? Software security expert Gary McGraw says:
For many years I have struggled with how to teach people . . . security design. The only
technique that really works is apprenticeship. Short of that, a deep understanding of
security design principles can help.
Assuming that the students already have some experience in computer security and with system design, I teach in the following manner:
Introduce security assessment as a part of security architecture
Introduce security architecture in its entirety, but with a focus on security assessments, in particular
Delve into understanding architectures
Practice architectural decomposition and following data flows
Introduce the ATASM process
Analyze architectures and present case studies

13.2.1 Training – Cont.
The entire project benefits from the exposure that active participation in a threat model gains. I walk through the ATASM process precisely as this book is laid out:
Learn the architecture
Gather all threats (brainstorm)
Talk about which threats are relevant to this system as it will be deployed for its purposes in the organizational context
Discover as many attack surfaces as possible
Consider existing security controls and possible mitigations
One of the reasons that organizations perform security assessments is to help ensure that systems don’t go live such that the system reduces the security posture of the organization in some fundamental way. This is a “due diligence” responsibility. In other words, the security assessment is, in part, an attempt to keep “bad things” from happening through the implementation and deployment of insecure computer systems.

13.3 Documentation and Artifacts
Security assessments must produce some documentation. Personally, I’m a big fan of keeping documentation as lightweight as possible. However, some organizations have more heavy-duty documentation requirements. Any organizations subject to certifications will have to produce sufficient evidence should the certification require proof that systems have been through a security assessment.
There are numerous, creative ways to produce architecture artifacts that are understood and useful to the architects and engineers working on a system. At the same time, the same documents are evidence of the threat model that has been considered, should your organization need such evidence.
Rather than offering checklists and templates, my methodology encourages people to follow every data path, check every flow of interaction, and identify all the inputs in systems. This approach does lead to peel-the-onion scenarios, which inevitably lead to backtracking through the ATASM process as new inputs and flows are discovered. I do find that this process does contain a map for completeness, if followed to conclusion, leaving no stone unturned.

13.4 Peer Review
What does a peer review process look like? When does an assessment require peerreview? Who should perform the peer review?
For large, complex, and challenging systems, there’s probably no substitute for a formal governance review. A common approach for this is to place senior and leader architects onto an architecture review board. The large or critical systems must pass through the review board and get approved before they can proceed. Sometimes, the review board will also have a checkpoint before deployment into production. This checkpoint helps to ensure that projects that haven’t met their deliverables can’t move to production to the harm of the organization. A senior security architect will be part of the formal review board and have a “no” vote if there is a significant risk that hasn’t been sufficiently mitigated.
This process does presume that architects will seek peer review. Architects have to perceive peer review as valuable and not a hindrance. If the security architects understand the responsibility that they hold for the organization, my experience is that security architects generally like to receive some additional assurance on their assessments when they feel at all uneasy about what they’ve found.

13.5 Workload
The problem of workload is further clouded by the simple fact that different people have different working styles. Some people can context switch very quickly, and some of these people may be able to retain a great deal of information about many different projects. At the other end, some very brilliant practitioners have trouble switching between contexts at all; even two may be too many.
New technologies emerge. New attack methods are discovered. And then there is the personal satisfaction that many security practitioners derive from staying up to date with current security events. The “right” workload also reserves some amount of time for project-focused and basic security research. Besides, up-to-date architects generally deliver better and more efficient assessments.

13.6 Mistakes and Missteps
Although my experience doesn’t perfectly match “Murphy’s Law,” “anything that can go wrong will go wrong,” mistakes and missteps do happen, it’s true. Perhaps by articulating a few of mine, I can save you from making the same errors?

13.6.1 Not Everyone Should Become an Architect
In that situation, there were numerous “architects” who didn’t have the capability, perhaps not the aptitude, for what the architect role requires. And remember, these people were senior to a lot of the engineers with whom they were working. That means that even though architecture decisions might not be the best possible solutions, those working underneath these new architects might have to implement something that was not ideal. Indeed, some of the engineers could see the mistakes being promulgated by the new architects, which led to a loss in confidence in the architecture practice.
This one mistake caused a three-year halt in the development of what eventually was an industry-leading enterprise architecture practice. It took several years to filter out those folks who would never gain the right skills or who didn’t have the temperament, while at the same time having to wait for the development of those who would take the places of the poorly promoted lot.
Not everyone can be an architect. Not every security person will be successful as a security architect. The lessons from those three years are burned into the way that I select candidates for the architecture role.

13.6.2 Standards Can’t Be Applied Rigidly
Frustrated teams escalated on a regular basis. Although there was no denying the contractor’s security knowledge, the binary, win/lose approach was causing projects to stall, velocity to drop to a standstill, tempers to flare. Though the person was a nice enough person and certainly easy to work with on that team, that architect was not working out at all in any programmatic sense. After all, architects, whether security or otherwise, are there to make projects successful. Part of the definition of “successful” will be to attain an acceptable security posture. “Acceptable” is a qualitative term that cannot be stated for all situations with engineering precision. “Acceptable” has to be uncovered.

13.6.3 One Size Does Not Fit All, Redux
Projects and changes to existing systems come in all variety of sizes, shapes, and amount of change. A successful program is easy to adopt when all who are involved acknowledge this variability upfront and clearly. I can’t tell you how many times an IT organization with which I’ve worked, in the name of efficiency, has built their delivery process around the biggest and most complex systems, only to bury innovation and creativity in a landslide of administration and bureaucracy.

13.6.4 Don’t Issue Edicts Unless Certain of Compliance
Edicts, unless based on the firm ground of necessity and obtainability, erode trust and support. In addition, if the directive is difficult or impossible to attain, such mandates cause your partners to create strategies of evasion or downright dishonesty, which means that you’ve made rules that people aren’t going to obey and you won’t know about it. I don’t like to turn delivery teams into liars so that they can get their jobs done. Edicts should be avoided.

13.7 Measuring Success
A poor measurement is the number of requirements written. A project that adheres to organizational standards will require few to no requirements. The security architect has done his or her job properly in this case. Adherence to standards is to be encouraged. My guess is you don’t want your security architects to believe that achieving success is a matter of writing requirements. If you do, you may get a lot of meaningless requirements or even impossible requirements that projects can’t fulfill. Bad idea. But I’ve seen it proposed due to the lack of useful measures of success. Instead, let me pose a couple of approaches that may help?

13.7.1 Invitations Are Good!
The focus on delivery implies that anything excess that doesn’t contribute to delivery is an impediment. If your architects are not being invited to meetings, are not being included in problem-solving discussions, this is actually exquisitely focused feedback. The first measurement for my program always is, are we being invited in and then asked to return?

13.7.2 Establish Baselines
Risk scores are interesting artifacts. First, these have to be gathered before assessment and sometime around the final governance checkpoint or project go live. Intuitively, one would expect risk scores to decrease. But this is not always what happens. Take the example of a project that, before analysis, presents as wholly following organizational standards. This adherence to standards will cause the risk score to below. Then, as the onion is peeled, it is discovered that one or more implementation details of the project present significant organizational risk and are not amenable to the organization standards. Such a situation is not common, but occurs regularly from time to time. I cited an example in a previous chapter. In this situation, the risk score is going to go up during the project delivery lifecycle. But the security architect is doing her or his job correctly; upon thorough evaluation, security issues are brought into visibility. That’s exactly the point of architecture analysis: to identify unmitigated attack surfaces.

13.8 Summary
Building a security architecture program is not a simple matter of hiring some smart people and then giving them some training.
A successful security architecture program depends upon the support and collaboration of those who will interact and see the results of the program. Building a strong network of support is one of the key communication activities of the program, even a mature program.
Finding the right people who have the relevant aptitude is, in and of itself, a nontrivial problem. Care must be taken to select for aptitude in a number of orthogonal areas: technical depth and breadth communication skills, sociability, and a predilection to think architecturally about systems.
Training can help to set a firm base upon which to establish experience. Naturally, I hope this book offers at least some basis for training security architects who’ll perform assessments.
Typically, security architecture programs don’t build themselves. There’s a fair amount of care and feeding that necessarily occurs to build a successful security architecture assessment program. Not to be too trivial, but it takes people, process, and technology.

Chapter 13: Summary
END
Dr. Sherri Brinson
sherri.brinson@ucumberlands.edu