Desktop version

Home arrow Computer Science arrow Securing Systems Applied Security Architecture and Threat Models


The final task of the business analytics analysis consists of finding mitigation for every attack surface that does not already contain sufficient protection to meet the security posture laid out in the description of Digital Diskus, above.

When I do these analyses for a real system, I list every requirement, even those that are already built. In this manner, I document the defense-in-depth through the security requirements. However, for the sake of brevity, the mitigations listed above will not be reiterated in this section. If you believe that an attack surface has not been sufficiently protected through this analysis, then by all means, reread the discussions above.

Since the quality of the software security being built into the system is not under the direct control of the organization implementing it (Digital Diskus), a key requirement will be repeated assurance that the vendor maintains rigorous software security practices, including finding and eradicating vulnerabilities before release; implementing input protections; and maintaining proper memory handling, proper multithreading and multitasking, secure web interfaces, and the rest of the panoply of software security design and implementation requirements[1] that secure software must meet. This requirement can be fulfilled by performing an attack and penetration test on all the inputs of the system and its software updates before the software is allowed to go into production. Particular attention will have to be paid to Data Gathering; Data Gathering and subsequent processing functions will require fuzzing tests in order to achieve some assurance that attacks will be rejected properly.

In order to prevent an attacker from obscuring an attack or otherwise spoofing or fooling the security monitoring system, the business analytics activity and event log files should only be readable by the security monitoring systems. And the log files permissions should be set such that only event-producing modules of the business analytics system may write to its log file. Although it is true that a superuser on most operating systems can read and write any file, in this way, attackers would have to gain these high privileges before they could alter the log files that will feed into the security monitoring system.

The administrative requirements for well-managed servers and services have been listed previously in several places. Table 6.1, for Web-Sock-A-Rama, contains a number of examples. And NIST 800-53 has been cited several times. For the purposes of brevity, the functions necessary to create a strong administrative defense will not be reiterated for business analytics (or for any succeeding architecture analysis). Please assume that the same requirements hold true for this system as it is analyzed in this assessment.

Table 8.1 summarizes the additional security requirements that Digital Diskus will need to implement in order to achieve the security posture required for this sensitive system, the business intelligence and analytics system. As we noted previously, requirements are broken down into three large categories: administration, network, and application. These categories are for convenience. Any other suitable abstraction can be used. The important point of the categories is to note that defenses are implemented at different layers throughout an operational execution stack. And, indeed, some of the requirements are not technical but rather process and even personnel oriented.

Table 8.1 is not intended as a complete listing of requirements from which the security architecture would be designed and implemented. As I explained above, when I perform a security architecture analysis, I try to document every requirement, whether the requirement has been met or not. In this way, I document the defense-in-depth of the system. If something changes during implementation, or a security feature does not fulfill its promise or cannot be built for some reason, the requirements document provides all the stakeholders with a record of what the security posture of the system should be. I find that risk is easier to assess in the face of change when I’ve documented the full defense, irrespective of whether it exists or must be built.

However, this is a pedagogical work, not an analysis of a living system. These architectures are merely examples[2] intended to help you, the reader, become more facile at analyzing the security of a system. As examples, I hope that you feel free to reread or even study any portions of the analysis, as you require. Consequently, Table 8.1 only lists those requirements that would be in addition to the mitigations that have already been documented above, in the mitigations section. In this way, I hope to keep the analysis more focused.

It’s always possible that I’ve missed something. If you will remember, at the end of the attack surface section, I asked you to check my work. Perhaps you came up with something that has not been discussed? If so, how would you protect that attack surface? That analysis lies at the heart of this book. Your risk sense may not coincide with

Table 8.1 Business Analytics Security Requirements




Typical industry standard controls have already been specified earlier. Please refer to these.

All modules and executables of the system must be hosted by one of the formal, corporate administrative teams.

All modules and executables of the system must be run on corporate- maintained hosts.

Administrative access to the storage areas for system configuration files and temporary and final results for the analytics must be restricted to a need-to- know basis and only to a small number of highly trusted and time-of-service proven administrative personnel.

Access to the permanent storage for the configuration files for the system and to the storage area for processing results will be granted only for the period required to perform an administrative task and then privileges will be revoked. Privileges will be granted only on a need-to-know basis.

Read and write privileges for system log and event files must be set in order to protect the files from inadvertent or malicious alteration. Only the business analytics module producing the event file may have write permissions, and only the security monitoring system may read the event or log file.


All executables of the system must run within the corporate internal network.


Fine-grained authorization to Reporter and Management Console functions will be employed. In particular, permission to add, delete, and write data source credentials must be restricted to a need-to-know basis. In addition, access to "executive" aggregations of business data must be restricted only to vice president or above personnel.

Authentication must be enabled before access is granted to the system for every user role and access. Authentication will be against the corporate, standard identity system.

Every input of the system must be self-protective and prevent malformed and other input injection attacks. Since coding of the system is not under Digital Diskus control, the vendor must demonstrate a successful attack and penetration test to include input fuzzing against all system inputs. All high- and medium-severity findings must be fixed in each software update before it may be installed on a corporate network.

For every data source that supports authentication, an authentication must take place before data may be accessed by the system.

For every data source that supports encrypted communications, encryption must be enabled to protect data as it is transmitted to/from the system.

Data gathering agents will be run only with sufficient system privileges to read the data to be gathered. Write/execute privileges on raw data sources are not required and must not be granted. Care will be taken to run data agents at a lower privilege than root, superuser, or administrator, if possible. If the operating system allows, a data agent should be run under a unique User ID assigned expressly to the data agent. Under no circumstances, should the data agent be run under the User ID of the user of the system or an administrator.

mine. I invite you to add or subtract from my lists as you see fit. For, in that way, you begin to make ATASM your own.

By now, I hope that you are becoming more comfortable with the ATASM process. Assuming that you no longer need to be reminded of the steps and how each contributes to the understanding of the whole and to each other—Architecture, Threats, Attack Surfaces, and Mitigations—I will no longer note the process as we analyze the remaining architectures in the following example assessments. Furthermore, in order to pace the remaining analyses, I will not list out the attack surfaces that are uncovered after the threat model phase of assessment. Instead, we will focus on the two most important products of architecture analysis for security: security requirements and residual risk left over after the requirements are implemented.

The requirements that result from the ARA/threat model process comprise the security posture of the system. It is the architecture requirements (mostly, the controls that will make up the system’s defense-in-depth) that become the security inputs into the architecture, as its developed, which then must be expressed by the design, and subsequently implemented in the software, hardware, infrastructure, operating system, execution environment, processes, and practices of those who will use, administer, and maintain the system. Without requirements, “securing” must be removed from the title of this book; only a risk assessment has been accomplished from the analysis. This book is about the process, tools, and craft of bringing systems of any size and type to a desired risk posture. The requirements that specify those mitigations and controls that exist and will be built comprise one of the essential goals of ATASM—that is, the “mitigation” phase of the process.

In a case where the requirements that can be built do not bring the system to the desired security posture, there is residual risk, as described in Chapter 4. Clearly stating any residual risk is also a key output of the ATASM process: Decisions will need to be made. Should the organization accept the risk? If not, must the organization invest in new capabilities in order to treat the risk? Does the system go live with the risks untreated? Or should the project be stopped until treatment, that is, mitigation is possible?

The task of the assessor is to present the residual risks in a manner that can be understood by each stakeholder community, each stakeholder type. In the organizations in which I’ve worked, it has not been the task of the security architect to render risk decisions (though in some organizations, it is). Instead, the security architect is the organizational “truth teller” who tries to convey risks in a manner that facilitates decision making. The architect has been charged with uncovering risks and assessing their organizational seriousness, a due diligence task for the organization, for which the security architect has been fully empowered.

It has also been the task of the security architect to understand who the appropriate decision makers are, depending upon the scope and seriousness of the risks that are to


be raised for a decision. The architect (or peer reviewing architect team) must decide the scope of the risk’s possible impact (consequences). The scope of the impact dictates at what level of the organization risk decisions must be made. The decision maker(s) must have sufficient organizational decision-making authority for the impacts. For instance, if the impact is confined to a particular system, then perhaps the managers involved in building and using that system would have sufficient decision making scope for the risk. If the impact is to an entire collection of teams underneath a particular director, then she or he must make that risk decision. If the risk impacts an enterprise’s brand, then the decision might need to be escalated all the way to the Chief Operating Officer or even the Chief Executive, perhaps even to the Board of Directors, if serious enough. The scope of the impact is used as the escalation guide in the organizations for which I’ve worked. Of course, your organization may use another approach.

Thus, there must be two primary outputs of the ATASM process, at the very least*: a set of architecture, design, implementation, and testing requirements and a statement of any system risks that the requirements do not adequately address in the presence of the threats the system will face when it goes live. In the succeeding analyses in this section, we will focus on these results.

In order that the remaining analyses are as brief as possible, we will proceed in a more realistic manner. As the architecture is understood, attack surfaces are uncovered. While fresh in the mind, requirements will be suggested at that point in the text. There will be no more lists of threats, attack surfaces, or mitigations. Rather, we will strive to develop as complete a set of security requirements as we can for each system analyzed.


1. Provost, F. and Fawcett, T. (2013). Data Science for Business. Sebastopol (CA): O’Reilly Media.

  • [1] For further information, please see my chapter, “Applying the SDL Framework to the RealWorld,” in Core Software Security, by James Ransome and Anmol Misra (CRC Press, © 2014).
  • [2] Every system presented in this book is based upon real-world systems that the author hasassessed. Nevertheless, these systems are entirely fictional. Any resemblance to actual systemsor products is purely coincidental.
< Prev   CONTENTS   Source   Next >

Related topics