Great matrix to see where you stand with your cyber security posture. If you have questions, or would like an evaluation conducted of your environment, please feel free to reach out to me at (605) 251-2131.
Thursday, May 7, 2015
What is your security posture?
Great matrix to see where you stand with your cyber security posture. If you have questions, or would like an evaluation conducted of your environment, please feel free to reach out to me at (605) 251-2131.
Saturday, May 2, 2015
Ransomware - should you pay?
Unfortunately, I have had cause to write rather regularly in recent times about ransomware, and what it can do to you. As straight-talking Naked Security writer John Zorabedian put it recently:
Ransomware is about the bluntest sort of malicious software you are likely to experience.
Ransomware shoves itself unavoidably right in your face.
It deliberately locks you out of your computer or your files, and then demands money to let you back in.
There are two main sorts of ransomware:
- Lockscreen ransomware. Pops up a window that takes over your computer or mobile device, so you can't use any other applications, make calls, or run your anti-virus. This ransomware usually accuses you of some sort of crime, but offers to let you keep on working once you have paid a "fine."
- File-encrypting ransomware. Leaves your applications running just fine, but scrambles your data files so you can't open them any more. This ransomware usually pops up a window offering to sell you the decryption key.
The bad news is that with most recent file-encrypting ransomware – well-known ones are CryptoLocker, CryptoWall and TeslaCrypt – there isn't a savvy shortcut.
Loosely speaking, if you don't have a backup of your scrambled files, you are stuck.
If the crooks have implemented the encryption process properly, the only way to get your files back is to to pay them for a copy of the decryption key. Public-key cryptography
Most modern ransomware uses public-key cryptography, which is where you have separate keys for locking and unlocking a file. The public key can be given to anyone to encrypt files, but only the private key can later decrypt them.
So, the crooks generate a public-private keypair on their own servers, and send only the public key to the ransomware running on your computer.
That means that the malware can scramble your data, but the key needed to unscramble it never shows up on your computer – not on disk, and not even in memory.
There's no point in scouring your computer in the hope of finding a local copy of the private key: your private key exists only on the crooks' servers until you pay up.
No-one else's private key will work for your files, either, so there simply isn't a shortcut.
You need that private key, and to get it, you have to pay the ransom.
What to do?
So the big question, usually left unanswered in technical discussions of ransomware, is, "Should you pay?"
At a typical price point around $300 to $600 (£200 to £400), ransomware can be expensive.
On the other hand, think about what might be in those scrambled files: your baby videos; those tax return documents you were supposed to keep for seven years; the dissertation you need to turn in on Friday...how much are those worth?
For better or for worse, most ransomware gangs have acquired a bit of an "honour among thieves" reputation, so that if you do pay over the money, you almost certainly will get your files back.
On the other hand, law enforcement and security experts are very likely to say, "These are crooks! This is extortion! If you can possibly take it on the chin, we urge you NOT TO PAY!"
But those are easy words to say if it's not your data on the line.
Interestingly, one reason for not paying extortionists is that there is often no way to ensure that they won't come back to gouge you for a second payment, or a third, and so on.
But, as described above, modern file-scrambling ransomware doesn't actually steal your files.
The crooks don't have a copy of anything of yours, just the private key to unlock the scrambled files on your own computer.
In theory, then, once you've paid up, decrypted your files and disinfected the malware, you and the crooks are back on an even footing, and they can't come back for more.
Should you pay?
We're not going to moralise about whether it's always unacceptable to support criminality by paying up, even if you are in a difficult position.
We'll leave you with plainer advice, namely, "It's OK to pay, but it's much better not to."
So, keep these two points in mind:
- Don't pay if you can possibly avoid it, even if it means some personal hassle.
- Take precautions today (e.g. backup, proactive anti-virus, web and email filtering) so that you avoid getting into a position where you ever need to pay.
After all, there's no-one you can pay any amount of money to in order to get your data back if your hard disk is at the bottom of Boston Harbour. (It happens.)
Wednesday, April 1, 2015
10 Tips for Cybersecurity
Protect Your Business
The Federal Communications Commission (FCC) has created the Small Business Cyber Planner 2.0, a free, online cybersecurity planning guide to help small businesses create a customized security program and protect themselves against cyberattacks. The FCC also offers these tips for improving cybersecurity:
- Establish security practices and policies and train employees to follow them.
- Protect information, computers and networks from cyberattacks.
- Create and use Internet firewall protections.
- Create and implement a cybersecurity plan for all mobile devices.
- Back-up important data, documents and information.
- Control physical access to your computers and create user accounts for each employee.
- Secure your Wi-Fi networks.
- Create security procedures for your payment systems and payment cards.
- Limit employee access to data and information and limit authority to install software.
- Create and use challenging passwords. Then, change them often!
The FCC Cybersecurity Hub for Small Businesses offers a variety of other tips, tools and resources
Tuesday, March 17, 2015
Dangers of Local Windows Administrator Rights
One of the questions that has come up, and it always does, is the question – how bad is it if users have local administrator rights?
Obviously the easiest answer is BAD, REALLY BAD! It’s like you buy a house or a car and then decide that you don’t need locks on any of the doors. The reason we have file permissions, registry permissions, user right assignments, and the like in Windows is to limit ourselves to only having the rights we need on a system that are necessary in order for us to do our jobs. We shouldn’t have any more or any less rights than are necessary. But when we give our end users administrator rights, it is like we’ve just taken all the locks off the doors and given those users the ability to go into any room of the house without our permission.
Ok, so beyond the simple answer, what else could happen on a machine if we allow users to be local administrators of their machines? Here are just a few of the things that could happen:
System files can be accessed or changed.
Program files or program configurations could be modified.
Software that is not approved could be installed, and won’t be maintained.
Malicious code can be installed with unlimited rights.
New, unapproved user accounts could be added to the system.
Password policies could be subverted.
Security controls such as anti-malware, firewalls, removable media controls, could be disabled.
And as you can imagine, the list goes on and on…
One other fun issue to consider is the issue of passwords. Many people have heard of the pass the hash attack where an attacker steals the local password hash from a machine and then replays it into the system’s memory whenever they want to authenticate as that user. This attack is certainly possible when users have local administrator rights. But wouldn’t it be easier if the user could just steal passwords out of memory in clear text instead? Well it turns out that’s possible too. Enter Mimikatz.
For a nice long, technical explanation of how Mimikatz works, there are plenty of nice tutorials (although to be fair many of them are in French). But here’s the bottom line, if your users are local administrators on their Windows machine, then they will by default have the user right assignment of “Debug Programs” (or they can assign themselves this right if it is taken away by a security policy). Once they have this right they have the ability to interact with sensitive portions of memory, such as those where authentication credentials are stored. With that information they are able to read authentication credentials out of memory.
Not only are we able to read the NTLM password hash out of memory – which could be taken offline and cracked or used in a pass the hash attach, but we are given the passwords for every logged in user in plain text. Even in the above example where the user is utilizing upper case, lower case, numbers, and special characters and a long password, there is no need for the time or computing resources to crack the password because it is there in clear text.
Many people might wonder at this point, is this only in older versions of Windows? Unfortunately the answer is no. Version 1.0 of Mimikatz works all the way through Windows 8 systems (although Windows 8.1 does appear to be safe). Version 2.0 of Mimikatz works even with Windows 8.1 systems to manipulate this type of information. And if you were wondering, yes, there is integration between Mimikatz and the Metasploit framework to make your penetration testing efforts easier. And, just because, there is also a plugin for Mimikatz for Volatility if you’d like to play with this tool with offline forensic memory dumps.
So once again, let’s restate the issue. How bad is it if end users have local administrator rights on their Windows machines? It’s BAD, REALLY BAD!! Both the Australians DSD in their Top 35 Mitigation Strategies document and the Council on CyberSecurity in their Critical Security Controls document list this issue as a serious concern. Hopefully we can all make sure to keep this issue in mind as we defend our systems.
Obviously the easiest answer is BAD, REALLY BAD! It’s like you buy a house or a car and then decide that you don’t need locks on any of the doors. The reason we have file permissions, registry permissions, user right assignments, and the like in Windows is to limit ourselves to only having the rights we need on a system that are necessary in order for us to do our jobs. We shouldn’t have any more or any less rights than are necessary. But when we give our end users administrator rights, it is like we’ve just taken all the locks off the doors and given those users the ability to go into any room of the house without our permission.
Ok, so beyond the simple answer, what else could happen on a machine if we allow users to be local administrators of their machines? Here are just a few of the things that could happen:
System files can be accessed or changed.
Program files or program configurations could be modified.
Software that is not approved could be installed, and won’t be maintained.
Malicious code can be installed with unlimited rights.
New, unapproved user accounts could be added to the system.
Password policies could be subverted.
Security controls such as anti-malware, firewalls, removable media controls, could be disabled.
And as you can imagine, the list goes on and on…
One other fun issue to consider is the issue of passwords. Many people have heard of the pass the hash attack where an attacker steals the local password hash from a machine and then replays it into the system’s memory whenever they want to authenticate as that user. This attack is certainly possible when users have local administrator rights. But wouldn’t it be easier if the user could just steal passwords out of memory in clear text instead? Well it turns out that’s possible too. Enter Mimikatz.
For a nice long, technical explanation of how Mimikatz works, there are plenty of nice tutorials (although to be fair many of them are in French). But here’s the bottom line, if your users are local administrators on their Windows machine, then they will by default have the user right assignment of “Debug Programs” (or they can assign themselves this right if it is taken away by a security policy). Once they have this right they have the ability to interact with sensitive portions of memory, such as those where authentication credentials are stored. With that information they are able to read authentication credentials out of memory.
Not only are we able to read the NTLM password hash out of memory – which could be taken offline and cracked or used in a pass the hash attach, but we are given the passwords for every logged in user in plain text. Even in the above example where the user is utilizing upper case, lower case, numbers, and special characters and a long password, there is no need for the time or computing resources to crack the password because it is there in clear text.
Many people might wonder at this point, is this only in older versions of Windows? Unfortunately the answer is no. Version 1.0 of Mimikatz works all the way through Windows 8 systems (although Windows 8.1 does appear to be safe). Version 2.0 of Mimikatz works even with Windows 8.1 systems to manipulate this type of information. And if you were wondering, yes, there is integration between Mimikatz and the Metasploit framework to make your penetration testing efforts easier. And, just because, there is also a plugin for Mimikatz for Volatility if you’d like to play with this tool with offline forensic memory dumps.
So once again, let’s restate the issue. How bad is it if end users have local administrator rights on their Windows machines? It’s BAD, REALLY BAD!! Both the Australians DSD in their Top 35 Mitigation Strategies document and the Council on CyberSecurity in their Critical Security Controls document list this issue as a serious concern. Hopefully we can all make sure to keep this issue in mind as we defend our systems.
Monday, March 9, 2015
Vulnerability Assessments vs Penetration Testing
There are many
instances where I have had discussions with an organization asking about the
difference between a Vulnerability Assessment
and a Penetration Test. So I
thought I would take a shot at identifying the differences between the two
types of testing.
Vulnerability Assessment is the process of identifying vulnerabilities on a network using a series of automated tools that scan the network for known weaknesses. A penetration test is focused on actually exploiting those weaknesses to gain unauthorized access to the tested systems or data (as directed by the client). A vulnerability assessment provides an overview of the flaws that exist on the system while a penetration test goes on to provide an impact analysis of the flaws, and identifies the possible impact of those flaws on the underlying network, operating systems, databases etc.
Vulnerability Assessments
use scanners to identify vulnerabilities that are known to report a great amount
of false positives. In Penetration testing, there is human
intervention to exploit vulnerabilities, thus eliminating false positives. Vulnerability
Assessments are more of a passive process. In vulnerability assessment you use
software tools that analyze both network traffic and systems to identify any
exposures that increase vulnerability to attacks. Penetration testing is an active practice wherein ethical hackers
are employed to simulate an attack and test the network and systems’
resistance.
Vulnerability assessments
deal with potential risks, whereas penetration testing is actual proof of
concept. Vulnerability assessments are just a process of identifying and
quantifying the security vulnerabilities in a system. Vulnerability assessments
do not provide validation of security vulnerabilities. Validation can be only
done by conducting a penetration test.
The scope of a
Penetration Testing can vary from a Vulnerability Analysis, to fully exploiting
the targets, to destructive testing. Penetration Testing consists of a
Vulnerability Analysis, but it goes one step ahead where in you will be evaluating
the security of the system by simulating an attack usually done by a malicious
hacker. For instances, a Vulnerability Assessment exercise might identify
absence of anti-virus software on a system or open ports as a vulnerability. However,
a penetration test will determine the level to which existing vulnerabilities
can be exploited, and the damage that can be inflicted due to this.
A vulnerability assessment
answers the question: “What are the present vulnerabilities and how do we fix
them?” Penetration testing simply answers the questions: “Can any external attacker
or internal intruder break-in, and what can they attain?”
Thursday, March 5, 2015
Top tips for educating employees about Cybersecurity
- Educate your employees and regularly talk to them, explaining the potential impact a cyber-incident may have on your operations. Employees need to know their obligations, especially when it comes to mobile data. It's not enough to require an annual review and signing of an "I have read and understand company IT policies" statement.
- Remember top management and IT staff. Top managers are often the target of cyber criminals because of their higher level of access to critical corporate and customer data. This increased access has a much bigger damage/financial payoff for the hackers. IT staff are also more vulnerable, given their administrative access over the network.
- The weakest link - Any network is only as strong as its weakest link. Explain to employees that while your organization is making its best effort to secure the company's infrastructure, it's critical that employees fully engage and do their part in following company policies. Policies should be sophisticated enough to cover all possible attack vectors.
- Social engineering - Warn employees to pay special attention to social engineering ploys they will find in social media, blogs and emails. It's also important to point out that many cyber incidents begin with a phone call from someone posing as a co-worker asking seemingly innocuous questions. Meanwhile, they are actually gathering information about the company and its operations.
- Recognizing an attack - Train employees to recognize an attack. It's critical that organizations have policies in place that assume they'll be infiltrated. Don't wait to react. Have a documented remediation plan in place and update or review it frequently. Communicate step-by-step instructions about what employees should do if they believe they've witnessed a cyber-incident.Training should include specific rules for email, web browsing, mobile devices and social networks. Don't forget the basics, such as physically unplugging the machine from the network and notifying the admin of any suspicious emails, activity or lost devices. Kaspersky suggests that employees should be able to locate their emergency IT contact number in 20 seconds or less.
- Notifications - If an incident happens, give employees a heads-up as soon as possible. A lack of transparency or improper handling of a cyber-incident may significantly increase the impact of the event. Issue instructions to employees about how to speak to the public and the press about the incident. Have an internal communications plan and PR strategy in place before anything happens. Consider insurance for cyber incidents.
- Regularly test employees - Organizations should regularly test their employees' cybersecurity knowledge and tie the results back into the training curriculum. It's important to make it fun and/or rewarding, with incentives for prompt responses
Subscribe to:
Posts (Atom)
Protecting Your Business From Your Remote Employees
A significant portion of your workforce is currently moving to perform full- or part-time remote work as a result of COVID-19. As you modif...
-
There's a new international survey on Internet security and trust, of "23,376 Internet users in 24 countries," including ...
-
The million dollar question everyone including myself have an opinion on. Here is my two cents. When you have the option to us...