I've been involved in a bunch of conversations recently around "baseline controls". What is the difference between different security controls, and how should we decide where to invest our money.
One train of thought is that any set of security controls that aren't linked back to something the business cares about have very limited value, because any breach of that control, or alert connected to that control is not going to get any response from the business. That without doing some form of risk based assessment, you can't select the appropriate controls or know what the right alerts and actions should be.
I tend to prefer a different train of thought, that there are a set of simple cybersecurity controls that are almost always always appropriate, in let's say 99% of contexts and situations, and that you don't need to perform a risk assessment or connect it to a business concern to make it useful.
I think the assumption that everything needs to be context specific tends to fall into the trap of assuming that there is a duality in the organisation, between the business and IT/Security. Somehow there is some magical part of the organisation that is "the business" that is the only part that really matters or has an opinion. If you don't have buy-in or acceptance from the business then whatever you do is not valuable. But people often can't really define who the business actually is in this case. You can point at the common suspects, policy and operational teams in government, editorial teams in a newspaper, and so on. But how about the estates team, are they the business, can they decide what security controls you should have around some of your IT systems? How about the HR team, the operations team, or the COO?
In reality, security and IT are responsible for their own security concerns, and they don't need to be driven by a business concern that is bigger or wider than them. They can decide that measuring the number of failed logins, or use of credentials out of hours from unusual geographic locations is the sort of thing that they should monitor without needing to have a business driver for that decision.
Further to this, I think within IT systems, there are a set of things that are worth logging and tracking because, regardless of the IT context, they provide value to detective, responsive or forensic teams. Even if your system currently doesn't track those things, and if you have no ability to react and respond to failed login attempts, once you know you are compromised, this information on logins will form a forensic trail that will enable someone to work out where the attackers went and what they did.
What is included in that baseline is a much harder question, but it's why I'm so happy to see tools like Logging Made Easy that shows a good attempt at an implementation of a baseline. I'm not sure it's perfect, but if I was looking for a starting place for such a logging baseline, it's a damn good working example.
Of course, the critical thing about a baseline is that once we've worked out what it is, it needs to be continually adjusted to keep up with technology changes, and to be continually raised.
Logging Made Easy is a self-install tutorial for small organisations to gain a basic level of centralised security logging for Windows clients and provide functionality to detect attacks. It's the coming together of multiple free and open-source software, where LME helps the reader integrate them together to produce an end-to-end logging capability. We also provide some pre-made configuration files and scripts, although there is the option to do it on your own.
Logging Made Easy can:
- Tell you about software patch levels on enrolled devices
- Show where administrative commands are being run on enrolled devices
- See who is using which machine
- In conjunction with threat reports, it is possible to query for the presence of an attacker in the form of Tools, Techniques and Procedures (TTPs)
This is a lovely project being put together by the NCSC. Designed for small companies that don't have a SOC, or even any logging, based on the experiences of the incident response teams turning up to organisations and discovering that there's nothing they can do, it turns on the most basic logging that you can get.
The huge value in this project is that they've actually set a sensible baseline policy for logging on windows desktops. The Group Policy that they've set turns on a simple set of logging events in the system, security and windows logs, as well as suggests installing SysMon and the SwiftOnSecurity sysmon config. This baseline is probably a good place to start for almost all enterprise logging systems as just enough data to cover the worst attacks, but not so much that you overwhelm your dashboards or collectors with information.
In a largely overlooked post published late last month, Microsoft said it was removing periodic password changes from the security baseline settings it recommends for customers and auditors. After decades of Microsoft recommending passwords be changed regularly, Microsoft employee Aaron Margosis said the requirement is an “ancient and obsolete mitigation of very low value.”
Further Reading Why passwords have never been weaker—and crackers have never been stronger The change of heart is largely the result of research that shows passwords are most prone to cracking when they’re easy for end users to remember, such as when they use a name or phrase from a favorite movie or book. Over the past decade, hackers have mined real-world password breaches to assemble dictionaries of millions of words. Combined with super-fast graphics cards, the hackers can make huge numbers of guesses in off-line attacks, which occur when they steal the cryptographically scrambled hashes that represent the plaintext user passwords
I first mentioned this back in CyberWeekly 51, but it's nice to see that Microsoft are making a big deal out of this. There's a lot of people out there who wont do this if security professionals say it, but will accept Microsoft's word on it.
After the war, the contribution of these women was overlooked and then forgotten. The CIA blossomed, becoming institutionalized, slick, and buttoned-down—a place where, in Purnell’s words, “brilliant masculine brains and well-connected college kids had taken charge.” Hall stayed on, but nobody quite knew what to do with the person one wet-eared upstart described as “the gung-ho lady” from the war. In 1953, the head of the CIA, Allen Dulles, convened a “Petticoat Panel” to look into attitudes toward women at the agency. Compared with men, they were seen as more emotional, less objective, and insufficiently aggressive.
A slightly depressing but interesting read into the female spies of the 40s and the attitudes of the same era. It would be nice to think that things have changed, but I suspect that mostly, it's just become less overt
This faulty code was in effect by August 17 of last year, and was only patched a few days ago on May 23. The live code was supposed to have been audited by GitHub and was also supposed to have been open-source. However, there was a difference between the original open-source code and the live code.
This discrepancy only started from August of 2018. Prior to that, both the live code was open source and generated unique public/private key pairs at all times.
The MyCrypto researcher ran a test on the generator. He used the Bulk Wallet generator in order to generate 1,000 new keys. When Denley used the GitHub approved version, he was able to generate 1,000 unique keys.
Next, between May 18 to May 23 this month, the researcher used the WalletGenertor.net live version at different times and in different statuses. However, no matter what time the test was carried out, and whether the user’s browser was refreshed, or VPN locations were switched, or even another user carried out the same test, only 120 unique keys were generated from each session
Oh dear. Crypto wallet attacks are the new crypto currency attack. Generate a weak set of private keys and users won’t know
Open-source reporting indicates nation-state actors have demonstrated intent and capability to leverage VPN services and vulnerable users for malicious purposes. The vulnerabilities are the ability of users to download untrusted VPN services and the lack of policy across organizations restricting their download. No overarching U.S. Government policy or whitelist restricts users from downloading a foreign VPN application on government-operated mobile devices.
Policy restrictions vary across departments and agencies. However, the number and identity of government operated mobile devices that have downloaded foreign VPN applications is unknown.
There may be no such devices.
The rise of fly-by-night VPN providers has been on the rise over the last few years and it is no surprise that using a less reputable VPN provider or one based in a less privacy-orientated legal jurisdiction might be worse than just using public WiFi to begin with.
It is peculiar that US government mobile devices (is this BYOD or COPE?) allow third-party VPN applications to be installed let alone connect (one would expect corporate VPNs to be provided and setup by default).
Agile, Scrum, and DevOps methods keep a specific project humming and evolving from conception to delivery, but they won't keep the work of a score of teams coordinated.
Creating a coherent design for a platform or application, of course, is a fundamental problem, and so is organizing the projects to implement such a design. But no matter how well you do at first, adjustments are needed.
Every one of those teams was set up to achieve certain objectives. Maybe they have an individual profit and loss (P&L), or Objectives and Key Results (the famous OKRs that Google adopted, inspired by Intel's use of them). But in a modern platform, almost all services that comprise the whole will use each other.
When someone shows up at your cube and asks for a new feature in the service you are offering or to fix a bug or to optimize performance, what do you do? Do you let them have access to your source code? If a new feature is popular with users or customers, do you keep it for your team or give it to the team where it may more naturally belong? If your team could add a capability that would help other teams make more money, should you do that before what is on your approved roadmap?
Anyone who thinks such issues are easily resolved and that everyone will just do the right thing has never worked inside a large organization in the real world.
Insightful deep dive into the way that Amazon solve some of these problems. Note that most organisations are not Amazon and trying to adopt this process wholesale, similar to adopting the read a memo in silence action will not transform your organisation. That's because the context in which these decisions are made is as important as they way they work. To use another analogy, moving Queen to E3 might be the right move in one game, but completely the wrong move if the other pieces are in the same place on the board.
But reading how other people solved these problems should help you identify where you can solve the problems in your own organisations
I used a bit of math (often quite basic!), IMPORTRANGE() and a smidge of Google Script to create a template Google Sheet spreadsheet and dubbed it the Standards Assurance Table.
The MOJ believes ‘security’ can work in the open so in addition to publishing it’s IT policies, as part of an open-sourced cyber security guidance microsite, the MOJ have published how the Standard Assurance Tables work and the theory behind them.
Some information risk management concepts were maintained such as maintaining the use of ‘evidence’ (documentation, drawings and so on — not hearsay) and ‘confidence’ (how well the assessor thinks the evidence demonstrates the target system is meeting the standard) but ultimately ignored existing information risk methodologies for the purposes of this work, to create a clean, simple slate.
A good strong data driven approach to risk management here. Allow individual risk managers and consultants to assess the compliance of an individual system, but creating an index document that can assess the totals and show where systems are consistently struggling to comply with a policy.
Software U2F authenticator for macOS
This is a lovely looking tool. Using the hardware enclaves on Mac's (where supported), it works a software U2F token like a Yunikey. It pops up and asks for permission to respond to the U2F where asked by websites such as the Yubico U2F Demo and proves access to the laptop. While one can argue that this may not be a "true" second factor, it does prove possession of an unlocked laptop, which prevents remote account hijack in a lot of cases.
I suspect this could very useful for people working in environments where mobile phones are allowed, or staff aren't issued with company phones to use for 2FA, and in those environments, this is probably better than no 2FA at all.
This PoC outlines a real-life attack approach in which a reverse shell is launched once the user opens the file. To conceal the attack, the file will be immediately rewritten when opened. Also, the PoC uses terminal escape sequences to hide the modeline when the content is printed with cat. (cat -v reveals the actual content.)
Now this is a cute exploit. A text file that looks normal to cat, but when opened in vim opens a reverse shell.