Jan 2nd, 2014 by Jesper Kråkhede
Remember the days of Melissa and Love letter? When you were breached it very visible and very clear to everyone in the office. Those days are over since long. Nowadays you may not even know that you have a breach and the only way to find it is using different surveillance tools to find anomalies in your traffic or in the users’ behaviours. At Darkreading I found an interesting article with 15 top indicators of a breach. While not all indicators are possible to implement for the small business some sure are easy to implement or easy to purchase as a surveillance service.
Unusual outbound traffic may be a first indicator that something is leaving your network. Large files going outbound in FTP or in HTTPS traffic may indicate something is not right. If your company´s normal network traffic is consisting of small files leaving via email you may have a problem. Getting a surveillance service up and running may be a good investment if you lack in other types of security or if you haven’t got the resources to have a full blown security department with 24/7 monitoring of network traffic.
I have always been a great advocate for context based sign-in and with the proper monitoring and tools you could easily find out when someone is behaving out of the normal. If you would to monitor my behaviour it would be typically normal for me to logon at 3 AM but very seldom at 6 PM. So if I were to logon that time either something out-of-bounds has happened or someone is doing something with my account, especially if the login came from a country I haven´t been in before.
Unexpected patching is another interesting indicator. Patching is good, patching often is better, patching out-of-bounds is worst. Even if you should have short patching cycles patching should not occur without your knowledge. A surveillance application that logs system changes is a very useful tool here.
Get your security services up and running today and you´ll be a lot safer! ?
Dec 19th, 2013 by Jesper Kråkhede
When I dig down into the bits and tin (Yes, I still do that on a regular basis as I strongly believe that you can´t be a good security architect without knowing both processes and technology as best as in humanly possible) one thing that my clients often are lacking is an In-case-of-a-breach-documentation (INCOAB-doc for short). What is this? It is mainly a collection of information regarding what may have possibly been lost with access to the system. It is not only a list of information objects and their possible value but also based on the different access levels that may have been reached, from read access in database to full system access.
This document makes it far easier to select the appropriate level of action to minimize downtime or to blow the whistle to close all systems until the breach is handled.
Dec 14th, 2013 by Jesper Kråkhede
What on earth is AML Security architecture? I sometimes get the question how you create a security architecture for AML (Anti Money Laundering) and I´ll try to answer it here.
A loose definition is that AML is a set of regulation dictating that you have to make sure your financial institution does not take part in laundering money from criminal acts, transfer money to terrorist organisations or in general not get involved in transferring money for criminal use.
So how does an AML Security architecture look like? First of all, it is quite complex and is not easily described in a short text but to start with it involves HR, IT and the executive board together with sections of compliance, auditors and the reporting office.
It all starts with a thorough risk analysis where exposure and threats are identified together with the possible actors and the markets your institution operates in. A special care is taken to identify the specific risks in your services and products. In special where large sums of cash is deposited and where there is a lower need of identification. All places where a lesser degree of identification is needed needs to be investigated in specific.
From there you make a quantification of the risks, make customer risk ratings based on clients geography, business structure, sources of funds, business types, products utilised and other identified risk factors.
Having the risk analysis concluded you identify the current security mechanisms in both technology and processes. You break up the risks into micro risks that could be mitigated with conceptual security mechanism. Taking the business process into account you insert the mechanisms where needed to mitigate the identified risks. This leads to a security architecture implementation program or in this case an AML program.
Nov 16th, 2013 by Jesper Kråkhede
Sitting at a local coffee shop discussing security architecture with a client is sometimes hilarious and sometimes very intriguing. Today I had two meetings regarding possible assignments for creating a security architecture. Both my clients are well aware of what security architecture is and what you need to do to create one but in one of the cases their management has no clue at all. In my first meeting we discussed how to create a security architecture to manage both their PCI DSS and legal requirements. During our meeting his CEO calls and tells him that he had found a free product that scans the whole network and produce a view of all systems and security mechanisms. If you give it full administrative access they even have a free service for managing the systems.
Do I need to say that we both did a unison face palm and redrew our project to include a risk analysis and education for the top management?
My other meeting was a lot more intriguing as the management is far more involved. Not only did they understand that we needed to conduct a risk analysis to get an understanding of the risks we need to mitigate, they also understood the connection to BCM and client satisfaction. In the end I was asked to propose a security architecture project to make their outsourcing services PCI DSS compliant and ‘Secure by default’. Most importantly is why the management formulated this assignment. Because they saw a clear cost cutting possibility by streamlining security services and at the same time minimise the down-cost due changes by unaligned security changes.
Nov 15th, 2013 by Jesper Kråkhede
As you may have noticed you can´t register as a new user on my blog. This is due to a large wave of spam attacks. I hope this to end in a few weeks so that I could open up for automatic registration again. Until then please drop a mail to crowmoor a t crowmoor dot se and I´ll make sure to register you.
Nov 15th, 2013 by Jesper Kråkhede
All those having a smart phone raise your hands! I´m one of those and I thought I had a rather good grasp of the smart phone security, the do´s and don´ts etc. but apparently I was mistaken. Do you know there is a second operating system running on your smart phone that has a large number of bugs and vulnerabilities, low to none patch management and was written during the 90´s when security was ‘optional’?
I just read an article where the second OS is outlined with a number of ways to exploit it outlined. It is not for the ordinary hacker but setting up a fraudulent base station is possible and with that they have total control of your smart phone.
So when you investigate your smart phone security you thought you were covered when you installed an anti-malware, encrypted your files and used https for web browsing or fetching your mails. Everything was covered and suddenly…a new threat emerges that been there since the 90´s that no one ever told you about.
Is this something to worry about? All risk are to worry about but as long as you are not communicating trade secrets, proposals, issues of national security or other stuff that could interest someone else you are home free. But it sure brings trust into the equation. You trust the phone developer to produce a secure phone or at least patch it to an acceptable level but do you demand this from your base station supplier? When you create the Trusted Computing Base take real care that you have included those that your trustees trust.
Oct 16th, 2013 by Jesper Kråkhede
If you are a proud owner of a D-link your best bet today is to hide in a dark place in shame. At least if you trusted D-Link to make a solid and secure product that is also cheap to purchase. Reading the link it is pretty obvious that D-link wanted to provide a simple auto update functionality for its customers but sadly failed miserably. With the external management interface enabled you have let your D-Link totally open for external control due to Joels backdoor.
So, in order to create a low-cost product, D-Link obviously has cut down on security testing. This sadly goes for most within IT. If it is cheap chances are that there are a number of security vulnerabilities and bugs.
Oct 15th, 2013 by Jesper Kråkhede
As some of you may know, at least those of you that have read my CV, I´m a trained social worker and have a keen interest in psychology. I always find it interesting to understand why some organisations manage to protect their information and why some fails.
I recently came across a report describing why users protect their information:
• They have a personal connection to it
• They truly understand the risk that exposure of the information poses
• The impact of such an exposure affects them directly
What does this mean when you try to educate your users? First of all you need to include your users in the security work and have them understand the information they are working with. It is not only numbers; the information is what makes them have a living.
Second: Include them in the risk analysis so that they understand the risks that are involved. In my models I work with micro risks, a tool that captures the small risks that every user perceive in their daily work.
Third: When making the asset valuation make sure to have them understand the consequences for them if there actually is a breach. Have them understand that a breach means that there is a huge cost and a potential loss of their jobs.
Sep 14th, 2013 by Jesper Kråkhede
I sometimes get contacted by CIOs or CSOs that have one single but really hard problem: How can I change my managements attitude to risks?
Mostly they have a management that accept almost any risk if the cost of controls run high. No matter what how the analysis is presented the cost is still perceived as to high. So, in effect, the risk analysis is null and void and the CIOs/CSOs just have to do their best and hope for yet a day without any incidents.
When I´m engaged, as a consultant, to deliver such a report I have a better position as I´m an external and therefor more trustworthy than the internal staff. Still it is all about balance and demanding responsibility to be able to get the management to understand.
First of all, when calculating the effects of a breach, I try to use real hard figures derived from a business down-situation. How much productivity is lost if ERP goes down? How long time does a restore take? What are the fines according to the agreements with the banks in case of a breach? Things that the management could understand and that is tangible.
Second, before I deliver the numbers, I´ll check for relevance and size. If I have a number like 12 000 000 000€ and net worth of the stock of the company is just 12 000 000€ I know that even if the fine and costs is very high it cannot be more worth than the company. So for relevance I cut the numbers down to size to make them more relevant. If a manager has a budget of 1 000 000€ the highest figure should maximum be 500 000€ otherwise it just become too high to understand. Just make sure that to include an addendum with the real figures and in your report describe why you cut the figures due to this and that. It is all about making exceptions that enables you to cut the numbers.
Third, make something more than a simple PowerPoint presentation. Print your slides, glue them to a large brown paper, tape the paper roll on a large wall, remove all chairs from the room and have your audience walk with you through the presentation. Takes a bit more work but you make a larger impact.
Fourth, put forward a paper where management has to sign that they accept the risk. This is down as standard procedure in ISO 27000 but you should emphasize it so that the management understands that they are responsible.
In the end, at least the CIO/CSO knows that he/she probably should look for a new job. ?
Sep 10th, 2013 by Jesper Kråkhede
I conduct several risk and vulnerability analysis every month. One part of the deliveries I make is a calculation of the financial impact in case of a breach. This is always a challenge but quite often I manage to get a fairly good figure. The hidden costs of a breach is quite often more of a challenge. On such hidden cost is the loss of productivity of the affected unit. Sometimes it is just as simple as the IT-department needing to work overtime but in case of a system down situation where your ERP is encrypted and needs to recover from a backup and all work made since the latest backup needs to be done again the loss is quite heavier.
I seldom work with brand damage as this is hard to measure in the first place and it all depends on how you handle the information to the public. However, it is a lot easier to start calculating the costs for the loss of a system, as a breach needs to be investigated and that will result in downtime.