2 hours 41 minutes
and welcome back
to Episode 13 off Cyber security architecture, fundamentals,
architecture documentation, Part one.
In this session,
we will cover a bit about
why do we need to do architecture documentation?
Cover some off the architecture art effects that you need to document
and go true. A few model views that that I used to represent a systems, namely the model view runtime view the plumbing view and data of you.
So why do we need to document the architecture
in any system life cycle?
We would have to create an architecture
idea from scratch or using architectural patterns, design patterns or from our experience, et cetera.
This is the same whether it's for a system all for software.
We were also need the ability to evaluate the architecture.
Is it good is it bet doesn't fit the purpose.
And with the feet back,
we would need to refine, update or effect earthy architecture along the way.
And once the design is final,
we used the architecture to guide the implementation
the same way a building engineer would use the architect's blueprints
And similarly, when the architect used the blueprint to enforce the design in building a building
in the same way
the software architect system architect. A cyber security architect.
We used the architectural documents to enforce that
the design is followed by the builders
and what pins the entire life cycle together.
So the architecture documents served as a conduit for clear and accurate communication off the design up and down.
for the document to be understood, offer the designed. To be understood, the architect must be able to communicate all the considerations behind every decision.
This would be your architecture decision documents, which will be covered in a next session.
Most architectural document starts in a piece of paper, a PowerPoint presentation.
But for more complex system, it's useful to have an architectural tool
to Lincoln all the various subsystems together,
it would be difficult to link 50 subsystems together death on an Excel spreadsheet or a piece of paper
final. What architecture, tools and use in your organization IDed system engineers or the software architects. They might have a tool that can be extended to the cyber security architect.
When we talk about architecture design, we have to cover all perspective.
We need to cover the processes the operations and the data flows. And not just the static technical deployment
a system list for a long time. The documents help in future re engineering projects. Sometimes people have to understand why certain decisions was made in a point of time
on the documents served. This purpose
an additional benefit off having good and clear documentation.
Yes, we can help to catalog assets that can be reuse. This would serve as building blocks for new projects that may come along after.
So what are the architecture at effects? Well, we've gone true moves of it in the early sessions off this course. First of all the trek models,
this is the basis off the design. Therefore, the trip models have to be captured accurately and clearly.
The tread models also help us to design the test cases.
S controls are put in place to mitigate the threats identified.
The test cases develop should also form part off your architectural documentation.
We would also need to capture the technical system designs. What are the platforms used? The components used in so far
and also the processes need to run the system.
How the system is deployed also needs to be clearly documented.
This includes the sizing requirements off the components that you need
makes. We have to document how we ended up into certain decisions.
This will be covered in an accession
and finally, any compliance checklist that you need to set this fire, the auditors or
Okay, let's get started on architectural artifacts or what use and software design. It's an example.
can consider the system in at least four ways
how it is structured and set of code. That's the model of you,
how it is structured as a set off elements that have run time presence. This would be the runtime view.
How are the artifacts organized in the fall systems? And how is the system deployed to heart way?
This would be the deployment view,
and lastly, what is the structure off the data repositories? This would be the date of you or the data mortal.
All these views refer to the same system. They're just different perspective for different stakeholders.
This is similar to a building architecture where you have the plumbing for the plumber,
the electrical wiring for the electrician and so on.
The architect must ensure that all the views are consistent.
Let's start with the modern view.
So this shows the structure off the system in terms of unit off implementation.
The elements in this view include the models, such as court units that implement such functionality
and the relationship between this morning,
is a part of B
are a depends on B
r A s A B specialization or generalization.
These can be drawn using standard UML,
which is the unified modeling language.
It is extremely useful to use standard notation for your diagrams so that its better understood
fire all stakeholders.
Next, we have to run time view.
This shows the structure off the system when its executing
the elements. Here are the runtime presence example T processes the threats, the serval, it's or the Windows applications. The deal. Els.
You would also show some of the data stores in use during runtime
and the relationships and these would be how the interact with each other.
Are they a local call or synchronize our asynchronous do not the examples I should underwrite.
There is the informal notation which is usually used in the presentation in the Power Point
and a formal UML notation below.
I would always recommend having a former notation use so that we could communicate with people, also your organizations, who will not be familiar with some off your own naming conventions.
In the deployment view,
we show at least two distinct but related structures
all structures of directories and fouls deployed in the system.
In this example, I shows that a heart where and the communication bus
and the second example shows the location off certain directories in certain service.
Again, do take note off the informal and formal notation.
While the informal notation looks good in a PowerPoint, the former plantation makes a lot more sense to a system or to a designer, especially if you're using
architecture tools to document your work.
The last few I'm talking about would be the data Mona view.
This should not be new to most people in 19. As this is thought and more schools,
you may ask, What is the value off this for the security architect? Well, sometimes the security architect needs to review the data models to ensure that the right data it's not exposed to the wrong person,
and it's helpful to understand the data structure when booting rules to detect unauthorized sequel cost, for example,
to go bore into details off this discipline.
Here are some Resource Is you can read.
Firstly, that's the System Engineering Book of Knowledge
which is a lot of information around system architecture and documentation.
And another good resource is the U. S. Department of Energy Enterprise Architecture Document, which is available online.
So to wrap up
in this session, recovered briefly the need to have proper documentation,
the various architectural artifacts and the various perspective models offer system
do re true all the reading materials to get a better understanding off why each one is important.
In the next session, I'll be covering on how to document architecture decisions.
So if you have the time, please join me. Thank you.