Download to read offline
More Related Content
Similar to Putting the Business in Enterprise Information Security Architecture
Editor's Notes
- #2 Presented at SecureWorld Expo Seattle
- #4 Putting the business into information security architecture begins with shaping your view of how the business determines state. Determination is made based on analyzing the current state “as is” and determined future state concept of “to be”. As this is the modeling behavior that most architects and business analyst use to drive the business it will also drive our agenda. AS IS is a discussion of the current state of affairs of information security architecture. Getting There is a discussion of what is necessary to move past the current state. TO BE is a discussion of how information security architecture looks once it has been integrated into the business.
- #5 Let’s discuss the current state of affairs facing information security architects. A point to note is use of the word enterprise has been mostly removed in their presentation. If you are an architect, you are more than likely in an environment that requires and currently utilized enterprise solutions.
- #6 SABSA directive based on a taxonomy approach similar to Zachman with integrations from Zachman. Both methods are a great way to start delving into architecture, however they contain the base elements only. You must provide the internals. Gartner’s directive is based on their BIT methodology of Business Information and Technology. BIT morphed to BITS with the inclusion of Security. TOGAF directive based on NIST recommendations which typically are used to design a program. The practioner is not told how to integrate security from a busienss perspective. Furthermore, the audience for TOGAF’s appears to be toward the EA has not had the opportunity to delve inside of information security, rather than a seasoned security professional. SOA and those who practice it have compiled first a set of security standards as it relates to SOA web and application development. In some cases, vulnerabilities exist that are not addressed; adoption of best practices from a myriad of sources exists. Of the methodologies mentioned, SABSA comes in first with understanding how security architecture can be integrated in the business. However, given the shift of organizational structure from siloed to matrixed as well as the adoption of agile development, none of these methodologies can be considered definitive without a support from other fields and disciplines. Additionally, they do not encourage agile response by the security architect in the provisioning of solutions. The litmus test for this assumption is based on the current definition of a security architect.
- #7 Remember the Where’s Waldo illustrations the late 80’s? The setting was usually chaotic, depicting a specific location or activity. The goal was to fine Waldo amidst all the chaos. Information security professionals face a similar challenge in operating in the business today. Business initiatives are kicked off and in most cases, information security is engaged toward the end of the project. This results in conflict as little change can be effect at times without impact the schedule of the project.
- #8 The security architect role follows a similar vein when you compare job titles against job descriptions and the required activities. In one case someone might be called an architect when in reality they are a CISO/ISO who must design and manage a security program. Others may actually be security engineers who manage the security technology of the organization. Still others may be a blend of an CISO/Analyst and Engineer. If you can’t find define the role, how can the business understand what services the architect will provide and how to engage them. When the business can not determine the need then the value is not assessed or appreciated as well.
- #9 One of the biggest issues facing not just information security architecture but many information technology disciplines is a lack of common language and standards. This may seem a minor issue. However, it can cause confusion when a group of subject matter experts must reach a goal but they cannot because each person has their own idea of simple terms. As an exercise, ask people in your organization what a guideline or a framework is. Then ask them what a policy is. If you cannot agree on terminology, don’t expect to agree on what the role of the security architect is or how it should integrate in the business. Developing a common language from which everyone is working will go a long way toward moving architecture initiatives along. To set the floor of your taxonomy, use terms that are industry standard that easily integrated into the culture of your organization. This becomes especially important if your organization is global or international or has out-sourced some activities.
- #10 A crucial point of agreement is architecture is what do we define as our artifacts. Google architecture + artifacts and the results will range from vague to explicit. This is not helpful when we consider an artifacts goal is to provide direction to move forward, help us to understand where we’ve been or why a decision was made. Artifacts are the resulting documents that provide a vision of the solution you are planning to provide or your environment. In some cases they are conceptual drawings, functional design or even narrative documentation such as a standard. Next is the question as to where they should live. There is little agreement or direction around where artifacts should live given their particular relevance to a project. This is risky when you consider that some of the resulting artifacts required of information security architecture must provide protection, mitigation and uphold compliance. Artifacts can be very powerful when used appropriately. They loose their power when there is not a clear definition of how they are used. Most organizations have policies. As policies are legal binding, require enforcement and compliance; enterprise architecture in general requires awareness and knowledge of policies when solutions are first conceptualized and finally developed. A lack of understanding of how artifacts are used once developed can undermine the best laid plans and result in a lack of confidence and trust with non-information security partners.
- #11 One evening on LinkedIn, I checked the Enterprise Architecture group discussions and found a posting the asked “Why don’t CISOs know about OWASP?” I was surprised as most of the security leaders I know are aware of OWASP. However given the question and responses, I recognized the existence of a perception that information security professionals in general may appear to be myopic to their business partners. To test my assumption I engaged a local well experienced enterprise architect and asked him a set of questions. The most relevant responses are shared here as they were the most meaningful. His responses provided confirmation that to a degree information security architecture really hasn’t been integrated into the business from a systemic perspective. As we’ve already discussed, there are constructs, principles, frameworks etc which exist; however they have not addressed the more important goal of business integration and alignment. Without reaching this goal, information security architecture will languish inside the business.
- #12 Information security overall has been fairly revolutionary; its had to deal with the blackhat community and the rise of the internet in most businesses and homes. It is evolutionary as it is never dormant; rather, it ebbs and flows between states of motion and states of rest. States of motion exist when the blackhat community provides threats that are new and for which there is little corresponding technology to manage the threat. States of rest exist, when the Blackhat community and corresponding technology has reached a state of counterbalance. What does this have to do with information security architecture? An analogy: The greatest building revolutions can take place when societies overcome a weakness or make a discovery that proves to be revolutionary. This cause results in the continued affect of systemic evolution. The question of information security architecture is given the revolutionary advances of the past 10 years, how have we evolved and what do we need to ensure evolution occurs that will embed information security architecture as a systemic discipline inside the business? Additionally, what is the current state?
- #13 We are at a time for great opportunity. If we look at the landscape of technology to malware development, we’ve reach a point of counterbalance. This has resulted in a state of rest so to speak for information security as a whole as we are not responding to threats in a reactive manner. Advantage is gained by using such periods to further revolutionize areas of information security that have not been systemically developed. In the case of information security architecture, the resting period is currently on of revolution. Security architects should take the initiative and consider the current (AS IS) meta data of methodologies, models, standards and constructs that define information security architecture today. This will result in identification of strengths and weaknesses as well as what suppositions have become obsolete. Such an analysis, leads us to the TO BE or future state that operates inside of the business.
- #14 We know we need to change. Lets discuss how can we do that without impacting the organizations we support and take the knowledge we have and channel it to greater success.
- #15 This means that instead of isolating smaller and smaller parts of the system being studied, systems thinking works by expanding its view to take into account larger and larger numbers of interactions as an issue is being studied. This results in sometimes strikingly different conclusions than those generated by traditional forms of analysis, especially when what is being studied is dynamically complex or has a great deal of feedback from other sources, internal or external. Enterprise architecture and its sub architectures of which information security is a part must look at the big picture to provide successful solutions. Becoming myopic or blind to any part of the enterprise results in lose of functionality, protection and most importantly, user satisfaction. Information security architects must have systems thinking because information security and EA operate in a dichotomy. EA drives the business forward while information security may seemingly quash innovation as it must protect the business and provide assurance in a transparent manner. Transparency of information security cannot exist if the security architect does not understand the partner disciplines it supports or must integrate with. Additionally, information security must look to the business and EA to determine protections. If a protection is not required, then it should not be suggested. Information security architecture must be truly visionary. When it is visionary, it becomes a compliment of the system is protects. It is not complimentary when over engineered to complexity for those who must support it and those who use the resulting system. We can achieve systems thinking for the information security architect through diversification. Understand how to protect the flow of data is great. However, is applied differently depending on the type of information data and where it is flowing. For instance the solution for protecting the flow of electronic mail is different than the solution that protects the flow of transactional messages into and out of a data warehouse. A lack of understanding around data warehousing and information architecture could greatly impact usability if a one size fits all solution were approached. Diversification of knowledge is what makes a successful information security architect.
- #16 If you look at most job descriptions of information security professionals, they ask for at least three of the five certifications listed. There are many more but these are the most prevalent. These are great certifications to obtain as a method for immersing oneself in the discipline of information security. The organizations which promoted these certifications are typically focused on information security and how it should be practiced from a autonomous perspective inside of an IT organization. There has been an effort by some to provide direction on how to gain visibility and oversight through governance. However they do not provide direction on how to align to the business. Nor do they provide you with knowledge of partner disciplines. When they do, then typically information security is the driver of the discipline rather then an integration component. If you are in an enterprise which most of us are, then you must become aware and comfortable with the disciplines you’ll partner with in the enterprise. Take the disciplines of the enterprise and use them as a middleware to integrate information security into the business.
- #17 In software development, middleware is used to support interoperability between disparate systems. For information security architecture innovation, non-infosec disciplines and practice can serve as the middleware to achieving success by supporting the business in a manner that is accepted. By learning at least two non-infosec practices in your organization, you are enabled to respond in a fashion that will allow you to easily communication with your business partners. This is how you move past being a analytical thinker to a systems thinker. Remember, analytics is more about focusing on points and is individualist in nature. Systems thinking is the aggregation of analytics around internal and external behaviors and interactions in a system. Of the recommended knowledge to gain, reverse engineering is perhaps the most valuable as it will enable you to gain a systems view of the information and guide your recommendations more accurately. Reverse engineering can tell you much about an environment. First and foremost it is an indicator of organizational maturity. Where standards are present, order is evident; where standards are absent, systemic chaos exists. Reverse engineering documentation is helpful as it can expose the lack of authoritative artifacts, the lack of supporting documentation and processes. Typically, if you lack documentation which means the organization may lack the maturity necessary to recover and continue operations in the aftermath of a disaster. Reverse engineering of a system is a learning tool as it will provide an understanding of how the technology is designed and how it operates. It can also help identify gaps in documentation or implementation. Reverse engineering from an architectural point of view is important as you must understand where you’ve been if you are to more accurately define where you should be.
- #18 Information security architecture benefits from systems thinking when the input of non-infosec disciplines results in the output clear communication, definition of scope, mapping of disparate entities to a whole entity that can respond to the complex demands of technology in the enterprise. Systems thinking also enables the security architect to make long-term recommendations and decisions that are sustainable as opposed to short-term fixes. Information Design is a crucial missing piece in the arsenal of many security professionals. It will help you present narratives or designs in a manner that is driven toward audience. The drawing you might provide to a director or above is much different than that drawing you’ll provide to an engineer or admin. Software engineering provides the synthesis around what we’ve discussed in the form of applying the concept of AGILE development to accelerate the top heavy and disparate approach of security architecture today.
- #19 As architecture is as much about building as it is about innovation it requires controls to support the design of systems that are extensible and sustainable. The lack of judicious controls results in over-engineering, chaos of component architecture, high cost of ownership to support and maintain a system. The most devastating is the delivery of a solution of end users that does not satisfy business requirements. Standards are the prescriptive control in information security architecture. Use standards to set the floor is to establish your baseline. It means you are working from an expected point that is backed up by the industry. Regulations such as HIPAA, SOX or PCI are explicit controls as they set ceiling of compliance and are not optional. Industry guidelines are the control that allow organizations to approach the development of systems typically based on national or global standards (i.e. NIST or ISO) Logic models illustrate the connection between your planned work and your intended results. YOUR PLANNED WORK describes what resources you think you need to implement your program and what you intend to do. YOUR INTENDED RESULTS include all of the program’s desired results (outputs, outcomes, and impact). Setting context is a method for aligning activities and services to the business and a control for eliminating scope creep.
- #20 Thus far we’ve discussed the AS IS or current state of information security architecture. Critical gaps in the current approach and how they undermine the discipline has been examined. Thought share around remedies to the current state has been introduced in the Getting There section of the presentation. Now we are ready to synthesize the AS IS and the Getting there elements to put business in information security architecture and make it agile. Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.
- #21 Business modeling like any process can be come arduous and waste time without its own set of controls. By containing it within a logic model, built-in controls are developed that drives the process to produce meaningful results. I have provided a link at the end of the presentation that can guide you through developing your own logic models. It can be quite useful in communicating complex data.
- #22 This is the Business Model Canvas developed by Alex Osterwalder. It’s one of the best logic modeling tools I’ve found to define and communication a business model. It consists of nine basic building blocks to show the logic that is required to drives a business: customers, offer, infrastructure and financial viability. Used correctly, it can serve as a blueprint, strategy or planning artifact for an organization. Take the time to research the SABSA conceptual and functional model. Then look at Gartner's BITS. If you are a business professional what do you want to see? It’s a business model representation as that is the point of reference business leaders are working from. SABSA and Gartner are for the architects use.
- #23 This is the business model canvas adapted to fit an information security architecture model. It is a prototyping tool used to build relationships with your partners but also build a business plan that will integrate and align with the business. This is what business leaders want to see. They do not want to see the SABSA model nor do they want to sort through reams of reports and analysis that focus on information security centric data. They want to know what its going to take to protect the business and revenue. Modifying the business canvas to compliment an architectural slant quickly communicates the business that you are aware of their vision and how information security architecture fits in to support it.
- #24 One of the most important outputs of architecture are artifacts. According to TOGAF, artifact represents an individual model of a system or solution, which could potentially be re-used in a variety of contexts. An artifact is distinct from a deliverable, which is a contracted output from a project. In general cases, deliverables will contain artifacts and each artifact may exist in many deliverables. Drive the definement of artifacts to streamline solultion delivery. Here we’ve defined two types of artifacts. Authoritative and Historical. They have very different uses and the audiences differ as well.
- #25 Considering the importance of artifacts, IT should agree upon the type of artifacts they will develop and their location. This is crucial if the security architect is to use the AS IS/TO BE methodology. If they cannot reference the past fairly accurately, visioning the future can become more time consuming. Artifacts are the ‘guts’ of the business and as such should be stored in a secure manner to only those that require access. Evangelize for your IT department where to store artifacts. Such a decision can make all the difference later on down the road when audits occurs or information management is addressed.
- #26 Setting context defines the conceptual layer that will drive the parent-child relationship of taxonomy-based architectural program. Without establishing the parent-child relationship of your program, you will likely offer services that do not align with the business.
- #27 The component architecture is based on a reverse engineering the infrastructure to understand boundaries, how they interconnect and support each other. This is why the infrastructure zone is at the top of the drawing. Different zones require varying levels of protection. Protection is accomplished through the application of countermeasures and controls. Select the countermeasures and controls you’ll used in your architecture solutions. Using a taxonomy-based approach, we determine what we are protecting by pulling the architectural concepts architecture context area. This enables the more granular identification of the infrastructure components we will protect. Controls and baselines are pulled from industry guidelines, standards and regulations. The component architecture should also contain any future technologies that have yet to be deployed. This will drive the AS IS and TO BE models without creating unnecessary overhead. In this drawing the future technologies are define by the color red.
- #28 The component architecture is based on a reverse engineering the infrastructure to understand boundaries, how they interconnect and support each other. This is why the infrastructure zone is at the top of the drawing. Different zones require varying levels of protection. Protection is accomplished through the application of countermeasures and controls. Select the countermeasures and controls you’ll used in your architecture solutions. Using a taxonomy-based approach, we determine what we are protecting by pulling the architectural concepts architecture context area. This enables the more granular identification of the infrastructure components we will protect. Controls and baselines are pulled from industry guidelines, standards and regulations. The component architecture should also contain any future technologies that have yet to be deployed. This will drive the AS IS and TO BE models without creating unnecessary overhead. In this drawing the future technologies are define by the color red.
- #29 At the end the of the day, you are already an expert with information security. Now its time to expand your horizons and add capabilities that will communicate simply what your mission, goals and activities are to non-information security professionals. Diversify your skill set to accomplish more.
- #30 I’d like end the discussion with the last bit of diversification. We recognize that technology and the development of technology takes places at a rapid pace. Information security professionals keep pace when they follow the driving disciplines. So I leave you with the AGILE model for information security architecture. The approach is both strategic and tactical. Steps 1 – 4 are purely strategic. Development will require business partner input. Steps 5 and 6 are of a more tactical nature and are owned by the information security architect. Steps 4-6 become iterative once solution architecture begins. Each solution project can use the strategic planning information previously gathered to influence the solution they will build using steps 4-6. This is how you put the business inside of information security architecture and make it AGILE.
- #31 Something I’d like to encourage all of you do to…when presenting in the future, list not only your online and book references, but also your people credits. We all meet people who are pivotal in growing or knowledge or professionalism. Don’t forget to mention them.