TISLA is a tool to assess the completeness of your technical information security landscape containing a 350+ question survey based on market best practices. The tool is built in Microsoft® Excel and can be downloaded on this site. Please read the licensing terms at the bottom of this page.
“The TISLA tool differs from the periodical pentest because a pentest “only” assesses the security of the scope you defined and if there are any exploitable or vulnerable weaknesses. It doesn’t say anything about how complete your defense is. The TISLA tool attempts to determine how complete your total technical security landscape is but doesn’t say anything about possible vulnerabilities in your infrastructure. It also says very little about your governance. The TISLA tool intends to cover the gap between security governance and pentesting, and tries to provide an extra measurement.”
This is a tool that helps Security Officers and other people to assess the completeness and basic design of their Technical Cyber Security landscape to gain a high level insight in this subject or use the results of the assessment to present to management. You can for example use the results to show the state of your Technical Security Landscape or to get funds for completing the picture.
It is a yardstick, nothing more, nothing less!
The main function of this tool is to be a yardstick against which you can measure the completeness of your technical security landscape. The tool links the result to a risk level. That level is somewhat arbitrary, but it does create insight into where you stand. You can then use this yardstick in presentations to your c-level management to justify investments in this landscape. In addition, you can keep track of progress in the field of technical security by means of periodic assessments.
Somewhere at the end of 2018 I was debating Cyber Security plans and budget for 2019 with my CEO. I tried to convince him some investments were necessary as he asked me: “Can you give me a grade of the status of our Technical Cyber Security on a scale of 1 to 10?”. I said to him I couldn’t do that because it’s not that simple. But the idea of such a grade or score for Technical Cyber Security got stuck in my mind and a few months later I started working on it. It was really fun to do it and I had some fellow professionals and old colleagues (see “Copyright” tab) who enthousiastically helped me putting the tool together.
This tool is NOT an exact science it is more like an indicator! It doesn’t tell anything about how secure you really are because that depends on a lot more than having your Technical Security Landscape all complete.
It doesnt replace a pentest or security governance it adds a tool in between.
So it doesn’t replace a pentest in any way. It only tells if you’ve covered the basics, measured against common best practices of the major technologies out there. The tool also doesn’t say much about Cyber Security governance. Sometimes there are questions about processes and policies and if they are subject to yearly auditing, but the majority of the questions are about the completeness and usage of the technology at hand. It has little to do with standards like IEC/ISO 2700X or any other standards. It does ask you to prvide a risc profile (ISO 2700X alike, or BIR / BIO alike for Dutch governmental organistions), so the tool can say something abou the risk level that the (in)completeness of your technical security landscape yields. In addition. Please bear in mind that this tool does not claim to have a hold on the truth. It is intended as a tool to assess the state of the basics of Technical Cyber Security compared to common best practices from a high level view.
This tool is about the right “onion”, the (technical) administration layers. The left “onion”, the governance layers are yust for reference and to provide a complete picture of all aspects of information security.
The six layers of the technical administration model are:
All these layers represent a tab in the tool. On top of that there is an additional 7th tab in the tool (not in the model) reserved for: “Gereral Technical Security”. It’s for things that don’t fit in any of the first six layers, but that you might want to consider in the total view.
Each layer is represented by an icon:
The questions are based on best practices. Most of these best practices are put together by consulting subject matter experts and some of them are put together by studying best practices on the internet and using comon sense.
If you have any suggestions, ideas for improvements or if you disagree with what you read, please let me know. This is a “version 1.0” and I’m convinced I can make it better with your help. If you want to contact me you can do this (anonimously, if you want) at the contact page of this website here: https://tisla-tool.org/contact/. Or you can join the discussion on https://tisla.slack.com/ (As a contributor your name will be listed, if you want that of course.)
Making this tool I struggled a bit with the fact that many technology manufacturers are putting multiple functionalities in their solutions. So “Detection” for example is not only done by IDS systems, it is also done by Firewalls, by logging solutions and many others. As security works in layers and multiple layers are always good it only strengthens your security. So you might encounter questions about some functionality in multiple sheets / chapters. Use this “cross solution functionality” as you see fit.
For the content of the layers of the “technical onion” I used the Lockheed Martin Cyber Security Controls Matrix which in turn is based on the Cyber Security Kill Chain. The most complete version of the model I could find is shown below in Figure 2.
This tool is structured in the same way as the “technical onion” (right one). The “double 6-layer onion model” is shown below in Figure 1. I know we can debate hours and hours on the order of the layers, the content of the layers an the order of the content, but I think it’s a good an usefull model. The TISLA tool represents the part in the blue circle.
The TISLA tool differs from the periodical pentest because a pentest “only” assesses the security of the scope you definedand if there are any exploitable or vulnerable weaknesses. It doesn’t say anything about how complete your defence is. The TISLA tool attempts to determine how complete your total technical security landscape is but doesn’t say anything about possible vulnerabilities in your infrastructure. It also says very little about your governance. The TISLA tool intends to cover the gap between security governance and pentesting.
First of all I used the above model. It divides Cyber Security in two parts: governance and technology. Both sides show a 6-layer “onion” with DATA and IP -that what we need to protect- in the center. It shows both the connection and the difference between the two sides of cyber security. I used it to separate things for my CEO and in the same time to make clear they’re both equally important.
Being a business administrator he had no trouble understanding governance, but he didn’t have a clue about technology. And because he didn’t, he opposed spending money on it, and he was very persistent in that attitude. So I decided to take this other approach. I wanted to create something that would help him understand what’s happening and why it is necessary.
So I came up with this double six layer information security model. I didn’t expect him to understand the technical part, that was not the goal of my model.
I explained what the six technical layers, the right onion, and its contents ment in laymens terms using analogies and pictures of mideval fortification defense systems (believe me, it works) and that created some very basic understanding. He had some “aha” moments. The main thing was that I made clear to him that technical cyber security is not so very different from defending your castle, but it requires a very broad and intensive field of expertise for those dealing with it. I told him I had developed a system to rate/score the technical security environment and made a relatively simple (and for the experts a probably too simple) link to risk… the risc that our ICT infrastructure would get compromised. And a compromised ICT infrastructure could lead to serious problems and serious costs, and there we were… Suddenly we had a yardstick that we could put along technical information security, something he could grasp, a figure, a rating… It gave him the feeling to be in control and provided a yardstick he could show to the board.
He finally accepted that he had to rely on the expertise of his security personnell for the nuts an bolts with just one condition. The only conditions important for him were risk, cost and their relation. So he should ask “what’s my risk, what’s the cost of that risk and what’s the cost of reducing it to an acceptable level” and not, “why are you spending loads of money on expensive abracadabra equipment”? I know, that’s the basis of information security, but my CEO needed the technical part to be more tangible, and that’s what this tool does. From that moment on my discussions with him turned around.
Besides of that, I’m convinced this tool also has value for CISO’s and other security personnell because it provides a way to “measure” your technical security environment against market best practices and it makes a connection to risc and enables you to keep track of improvements over time.
At this moment the TISLA tool is most suitable for On-Prem/Private Cloud, IaaS, and partly PaaS. There is no specific functionality / technology covered for (full) SaaS environments yet. This functionality will be covered in the near future.
The tool consists mainly of a large number of “Yes/No/Don’t Know” questions and a small amount of “%” questions which have limited choices. The scoring of the “Yes/No/Don’t Know” answers is as follows:
In addition, you can see in the score that I have applied a multiplication (weighting) of 1, 2 or 3 times when calculating the total score. And yes, I know, the eventual levels are pretty darn ambitious. You can use the tool for the total landscape, for a single domain or even for a single technology / solution. That’s your choise.
The tool needs a risk profile of your company as an input in order to return an indication of the risk that is in the (in)completeness of your Technical Security Landscape. I have chosen to put two risk options in the tool:
Why BIR / BIO
I chose to add the BIR / BIO standard because duringthe time I developed this tool I was working for a company that worked exclusively for and was funded by geovernment. The BIR / BIO is an ISO 2700X-based standard that is expanded by 140 extra government related measures. This security governance standard is required by law for all government agencies in the Netherlands. Because our company worked exclusively for Governmental agencies, this standard was a logical choice.
Some freedom in selecting risk profile
Normally the risk levels would be provided by thorough risk analysis and data classification, but you have complete freedom to estimate the risk yourself and to keep the tool flexible. The risk level you choose is used to estimate the risk that is in the (in)completeness / configuration / composition of your Technical Security Landscape.
The entire assessment is a simple 3 step process where the majority of the work is in step 2, answering the questions.
The tool calculates everything to a 0 to 5-star rating (so it provides no figure from 1-10, although you can translate the star rating to a figure).
Next to that there is a stoplight indicator:
As privacy is becoming more and more important and law and regulation is demanding good practice at the risk of high fines I decided to incorporate some Privacy related questions. I incorporated this because Privacy and Cyber Security go hand-in-hand. Privacy and Cyber Security sometimes conflict, but good Information Privacy cannot exist without thorough Cyber Security. On the other hand, Cyber Security can be intrusive when it comes to Privacy of your employees or even your customers. That is why I have devoted a small part of this tool to the relationship between cyber security and privacy practices.
©Copyright (c) 2020, Tom van Thiel – TISLA-TOOL.ORG, All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
THIS SOFTWARE IS PROVIDED BY TISLA-TOOL.ORG AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL TISLA-TOOL.ORG AND CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
