It can be a difficult job trying to plough through the many professional institution emails that emerge these days. In an attempt to make emails more attuned to the members, BCS has under the ITNow branding overhauled their approach to email comms.
With the second edition of a new-look weekly newsletter now in circulation, BCS have chosen to entirely replace the specialist series of newsletters. This followed on from a recent member consultation where members indicated they wanted regular industry news updates, events, articles and blogs.
The BCS membership magazine ITNOW is positioned as “the voice of the Institute”, and has both a member readership and wider readership.
BCS members should see this change automatically reflected in their communications from BCS.
High on the cyber security news in the last couple of days has been a discovery that Facebook stored far more passwords in plaintext form than previously thought.
The issues at Facebook highlight the importance of secure development practices, including development of policies that ensure developers adopt the correct practices for authentication.
Ensuring passwords are stored in an irreversible format, salting, centralising passwords and prohibiting their distribution, restricted access to credential stores, and using 100k+ hash stretching, are just some of the techniques needed in good solutions.
But thinking ahead, the discovery simply underlines the potential impact of a password breach further down the line. As users tend to re-use passwords across multiple systems, the ever-present risk is that a password list from any company (not particularly Facebook), is used in attacks against your infrastructure.
The conventional approach to managing password security is to enforce a password policy in your environment, for example using a GPO in AD or pwquality under RHEL. A wide variety of parameters can be configured that make it less likely, but not impossible, to avoid a password shared with another system, including:
- Limiting the numbers of upper case and lower-case characters
- Requiring minimum number of specific character classes (digits, uppercase, etc.)
- Limiting the number of consecutive same characters
- Retaining a history of previous passwords used, and prohibit their re-use
- Specifying a minimum password size
- Enforcing a minimum password age (to prevent password reset malpractice)
- Configure account lockout
- Limiting the number of digits in password (e.g. to discourage phone numbers or bank accounts)
- Limiting the number of character sequences from old passwords that can be re-used
- Enforcing a maximum password age (forcing password change)
In practice these kinds of policies are enormously difficult to operate in anger. The number of constraints imposed in a password policy quickly exceed the ingenuity of users to create unique passwords when required by the system, reducing usability and processes being broken. This leads to passwords being written down, or rules-of-thumb being devised that satisfy the password policy but nevertheless are weak once the pattern is known by an attacker. Password complexity rules can work against information security if implemented incorrectly, and so must be tuned carefully.
No policy of this kind can conclusively address the risk of a password reuse being exploited. This is where second-factor authentication can provide significant assistance, requiring (typically) something the user has, to considerably reduce the attack surface in the event of a password reuse attack (e.g. credential stuffing). Deploying 2FA on all public-facing interfaces is a must and is increasingly advised for all Domain logons.
But 2FA is not perfect, and has a number of significant disadvantages, including its exploitation to deny access to accounts (through a compromise of the 2FA infrastructure), the loss of the factor itself due to misplacement or theft, malware, typically weak account recovery processes in the event of the second factor being lost, attacks against the core of 2FA, or a situation developing that challenges the norms assumed in 2FA usage (e.g. power cuts preventing phone charging, disasters leading to mobile phone network outages, etc.)
The disadvantages of 2FA have led several organisations to withdraw 2FA from their IT estate (e.g. reportedly Apple Inc.)
This leads to the inescapable question of whether something more can be done with password breaches to conclusively address the issue, such as by targeting the passwords breached in the first place. With some ingenuity it is possible to develop better password management schemes that target the specific issue of password re-use.
Technical measures that target password re-use are essential, particularly if 2FA is not intended in some or all authentication use-cases – for example authentication of customer accounts online.
Microsoft Azure announced in Q4 of 2018 that their Premium subscription customers would benefit from enhanced password vetting through the Global Banned Password List (GBPL). This is a dynamic list of passwords considered to be vulnerable by Microsoft, which are blocked by Microsoft in password set/change requests. The GBPL can also be supplemented using an organisation-specific password ban list, e.g. developed from data breach password feeds.
Schemes like GBPL are precisely targeting the password reuse problem and are worth factoring into any future IdAM strategy.
Of course, live verification of password suitability of the kind offered by Microsoft is the holy-grail in some respects, but in practice such high levels of integration can be difficult to achieve. GBPL capabilities for Azure is only available for Premium customers. For most enterprises now, the alternative (and preferred approach considering the above) is to check passwords offline using a compromised password list. Troy Hunt has made the HIBP compromised password list available for download (c. 6GB). This can easily form part of a solution for password security management.
NIST have made checks against known compromised password lists a requirement, so it is important to consider password re-use attacks in all enterprise infrastructure. A word of caution though: there are many scripts and tools available that are capable of checking passwords dynamically, using public APIs and data sources. It’s clearly inadvisable to use any tool or script that transmits a potential new password (or derivative) beyond your enterprise infrastructure to a third party when configuring authentication, even they could be considered to semi- or fully-trusted.
Alert from US-CERT NCAS:
It’s time to review the retweets from the tweet feed!
Containerisation is rapidly growing in popularity, but the security model for containers is very different to conventional application deployment. Red Hat have some useful observations (https://www.redhat.com/en/topics/security/container-security):
- Existing static security policies and checklists do not map across to containers easily
- Security policy service in the supply chain needs enhancement
- Signature checks of containers and base images is essential
- Is the runtime and OS up to date?
- How often will the container be updated?
- How are containers going to be managed and protected?
- How are you going to segregate production and non-production images?
- How are containers going to be segregated in the infrastructure?
- Is availability and scalability addressed?
- What monitoring arrangements will be in place?
A wide range of familiar security issues surface when using containers, and it’s easy to overlook these by not understanding the technology. Get architects and information security personnel in a room and develop a practical policy and plan.
Adobe critical security patches issued
Adobe are releasing updates again, and as before the number of critical security updates are significant. It’s important to evaluate how you use Adobe products, as with all software products, and ensure you have effective technical security management of the one place where Adobe products can be highly exposed: web browsers and file associations in general. See my previous post on PDF security for some further ideas.
NIST RMF updated
Nvidia fixes high-severity embedded board vulns
This is yet another example of how hardware vulnerabilities could present significant risks to an organisation, although in many cases the exposure to these risks is limited and exploitation is complicated. More broadly though, it’s a timely reminder of how the cyber security of the supply chain is managed:
- Ensure the origin of products used in systems are understood and risk managed
- Make sure procurement, supply chain and other organisational processes are linking up to the obsolescence and supportability agenda
- In simple terms, make sure you don’t buy old products that are due to go out of support and lose patch supply
For a lot of organisations, the biggest challenge will not be in managing the supply chain and patch flow, but in actually executing the patching process when hardware-level patches are issued. All the usual challenges crop up: resources to manage patching, getting coverage as quickly as possible, managing mobile devices off the network, etc. Get the basics right!
Google patches and the Android ecosystem
Android devices are now commonplace in enterprises who issue devices to employees, and there are some useful capabilities from manufacturers like Samsung (Samsung Knox).
But, the industry findings and press on mobile devices in enterprises can be unpleasant reading. Here are some stats (https://danluu.com/android-updates/):
- There are over 2 billion active Android devices
- Over 1 billion Android devices and tablets are out of date
The Android ecosystem, where vendors branch and manage their own variant of Android, is clearly one of the contributory factors. In this scheme there is little incentive for vendors to continue to issue security patches for Android, at a cost, when new devices can be sent to market, at a profit.
This is really an “economics of security problem”. It is not surprising therefore that vendors are issuing patches more slowly than their creator, Google, or not issuing patches beyond a relatively short time horizon.
We’re getting to a point as an industry where it might be a better policy position to source Android devices for corporate networks from Google, or at a push, from a small number of top-tier Android device manufacturers (e.g. Samsung). A good example of such a device is the Google Pixel, which is recognised as the first to receive updates from Google, with updates being issued within 2 weeks and an end of support duration of three years. This compares very well to other Android devices, some of which are now obsolete.
Should all enterprises issue Google Pixel devices if Android is needed? It might be a smart position to take, but make sure the end of life date is factored into procurement.
Carbon Black highlight supply chain security
This is a concerning but not surprising finding from the highly-respected Carbon Black. The supply chain has always been a point of vulnerability for organisations who don’t manage their supply chain cyber security effectively. It’s why 27001 was updated in 2013 to include a set of foci specifically on the topic of supply chain cyber.
How supply chain security is managed is critically dependent on procurement processes in an organisation. Cyber security must become an integral element of procurement processes to achieve a baseline, allowing information security teams to provide added value on top of that.
It’s a broad topic, but at the core the supply chain should be managed like an in-house information security capability: strong risk assessment and treatment activities, in a way that supports the business. There are clearly some unique challenges in supply chain security, particularly around how security is evidenced, when and how.
BCS have recently launched a new certificate in AI. It aims to provide a full overview of AI from the risks and benefits, through to ethics of AI, and is well worth a look if its a topic of interest.
Interesting run through of the potential vulnerabilities in supply chain cyber from Sophos:
This of course highlights the illusory nature of package management security that we rely on so much today. A given software package might have a valid digital signature, from a reputable CA, but it says nothing of the security behind that in the cyber supply chain.
Relying on encryption as the solution, which is the de facto position for virtually all sofware distribution channels today, simply shifts the risk to the weakest link.
That handy piece of freeware your business is using to save time on remote administration? The security of your enterprise is now dependent in part on the security of that freelance developers laptop, which makes its way across the world to conferences and is regularly on a table in coffee shops. Sure, the code gets signed, but is it really that secure overall? Probably not.
This is a very simplistic example, but it does show how much is unknown in cyber supply. The patch management infrastructure and policies set in many organisations simply facilitate the compromise of infrastructure, in the event of supply chain compromise.
I expect we will continue to see this occur. But there are things that can be done:
- Develop and issue cyber security supply chain policies
- Inspect installed software and aggressively remove unauthorised or non compliant installs
- Review and vet software introduction
- Have a rigorous patch management policy
- Inspect updates using multiple sources for comparison
- Use non-attributable connections
An interesting article in Network World.
This caught my eye: “While VLANs have historically been used to segment traffic, they do not have adequate security and are not able to seamlessly span distributed network environments. Instead, organizations should consider using Internal Segmentation Firewalls (ISFWs) which provide the scalability, span of control and performance inside the network that traditional NGFW solutions can’t match, as well as the security and span-of-control that VLANs don’t provide.”
Overlooking the spell check correction in the title*, there is an interesting article by SC Magazine today showing APT use of encrypted payloads in images as a covert channel. As the article notes “researchers uncovered a novel payload loader that uses steganography to read an encrypted payload concealed within a .png image file”.
Source and further reading – https://www.scmagazineuk.com/stenography-used-oceanlotus-apt-instal-denes-remy-backdoors/article/1580945
* Stenography is concerned with handwriting analysis
An important event in BCS socialisation of diversity and inclusion:
“BCSWomen Lovelace Colloquium, the UK’s main conference for women computing students. Aimed at women, open to all.
Keynote Speaker – Helen Leigh: Maker, writer, lecturer, musician & nerd. Wrote The Crafty Kid’s Guide to DIY Electronics. Made the MINI·MU glove. Other speakers include women from Bloomberg, the BBC, and University of Salford. Posters will be displayed by women students studying at Universities from across the UK, from Aberdeen to Portsmouth. Plenty of time for networking!
10.20 Keynote: Helen Leigh
11.20 Coffee break, with posters going up
12:10 Lunch & poster contests
15.30 Coffee break, posters coming down
16.00 Panel session on computing careers
16.45 Close & prizes
The aims of this event are:
To provide a forum for undergraduate women and masters students to share their ideas and network
To provide a stimulating series of talks from women in computing, both from academia and industry
To provide both formal (talks) and informal (networking) advice to undergraduate women about careers in computing from a female perspective
For overseas delegates who wish to attend the event please note that BCS does not issue invitation letters.
“Please note there will be event photography for the duration of this event. These photos may be shared on University social media channels and/or the University website during and after the event. If you do not wish to have your photo included, please inform a member of staff on arrival at the event” ”