The Rational Approach to Disruptive Information Security
1. Information Security
Science
The Rational Approach to Disruptive Information Security
By Ravila White, CISSP, CISM, CISA, CIPP, GCIH, ITIL v.3
Making it better without making it complex
2. Disclaimer
This presentation and the concepts herein are
my opinions through private research, practice
and chatting with other professionals.
It is not the opinion of past, present or future
employers.
3. Agenda
Checklist(s) – What is wrong about them…
Understanding Disruption– It’s the driver
behind technology we must secure…
How to be disruptive – NIST can help you
but…
5. Find a standard
Find a best practice
Perform a gap analysis
Train our users
All the boxes for the auditors are
checked
Going down the wrong path…
6. Why?
The solution must meet the use case
The solution must protect against real
threats
Solutions must align to business
operations
8. The reality is…
Business is not linear
Business is driven by innovation
Business is driven by disruption
Knowing is not understanding. There is a great difference
between knowing and understanding: you can know a lot about
something and not really understand it.
[Charles Kettering]
9. How we got here..
Not understand the mental model of our
organization
Not adjusting our mental model
Implementing mental models based on
checklists
11. Disruptive Technology and/or
Innovation
Creating a new market or value network
Improve a product or service
Designing for a different set of consumers
“It represents a mindset—a rebellious instinct to discard old
business clichés and remake the market landscape. An
eagerness to deliberately target situations where the competition
is complacent and the customer has been consistently
overlooked or under-served.” [Luke Wilson]
12. “The potential for reinvention is all around us, and it’s an exciting time
to be thinking about how to structure (or restructure) your business,
your community, or your life in ways that create new value. Enjoy the
possibilities.” [Richard Branson - 1998]
Innovation Disrupted Market
USB Flash drives
Downloadable digital media
Minicomputers
Digital photography
Steamboats
Automobiles
LCD
GPS Navigation
Floppy Disk drives
CDs, DVDs
Mainframes
Chemical photography
Sailing ships
Rail transport
CRT
Navigational map (paper)
15. How Mental Models Influence
Business Process Modeling –
communicates intent and value to the
organization
Enterprise Architecture – sets the context of
information security within the business
Information Design – helps non-infosec
partners quickly orient themselves in a
complex environment
Software Engineering– provides synthesis
of complex information into a whole
19. Reversal through ISO7498
Authoritative
◦ sets the direction
◦ the business validates its decisions
◦ the business executes against
◦ the business captures resource
requirements
◦ the business verifies the activities
necessary to support a solution
Historical
◦ Project plans
◦ RFIs and/or RFPs
23. Credits & References
General Professional Influencers
Disrupt: Think the Unthinkable to
Spark Transformation in Your
Business
Google: www.Google.com
The Visual Miscellaneum
Change by Design
Thinking Page: www.thinking.net
Wikipedia: www.wikipedia.com
Colleen F. Ponto, Ed.D
24. Copyright Information
Some works in this presentation have been
licensed under the Creative Common license
(CC). Please respect the license when using
the concepts or adapting them.
For more information please go here:
www.creativecommons.org
Presented at SecureWorld Expo Seattle by Ravila White
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.