Quali survey: Infrastructure, fragmentation of toolsets among top barriers for DevOps adoption – SD Times


In Quali’s latest survey, over 2,000 IT executives shared their thoughts on the primary challenges they face when adopting DevOps.

HT @mark_royle

Source: Quali survey: Infrastructure, fragmentation of toolsets among top barriers for DevOps adoption – SD Times

ASD Essential Eight and Enterprises


The Australian Signals Directorate (ASD) has updated their top four mitigations for intrusions. The recommendations have now expanded to the ‘Essential Eight’.

The essential eight is a short list of the top eight mitigations govt and businesses can adopt to reduce the threat and likelihood of a successful IT security and/or information breach.

This article examines the eight recommendations and which ones I consider a *MUST* for private enterprise. Government agency’s should use their own info-sec policies to determine their own approach and that’s a topic for a different post.

Of the eight mitigations described by the ASD, the following four key items for business are critical:

  • Patch Operating Systems and Applications
  • Restrict, control, monitor and audit privileged account access and use
  • Use 2FA/MFA authentication
  • Backup data and offline storage

Lastly, the other three items are briefly described with justifications for why they aren’t a *MUST* do.

Patch Operating Systems and Applications

It goes without saying that regularly applying operating system and application patches to any system is a must. This is a well known mitigation and has been recommended practice for many years now. Operating system vendors now have mature and robust tools to allow businesses to quickly understand the patch level of existing systems and easily approve patches for distribution and installation.

Applications are a different problem. The recent Apache Struts vulnerability and the openssl Heartbleed exploit in 2014 are good examples of complex application vulnerabilities. In both these cases it wasn’t vendor products or services which were directly vulnerable but the included underlying libraries and code which was.

This type of problem is difficult to manage since, as a consumer of a SaaS offering or CoTS product, it is very difficult to know precisely what other code vendors include in their offerings.

Couple these complexities with busy teams, reticence to touch or change old or fragile systems and its no surprise that application vulnerabilities take a long time to be patched.

Robust and regular operating system and application patching is highly desired but may no be easily attainable. There are other options to further mitigate this risk however.

Automated vulnerability scanning can be used to regularly scan and interrogate systems and their software inventory for known exploitable code. These systems can present threat telemetry (or alarms) to operations teams. This allows informed decision making so that limited and valuable resources can target the areas of highest risk.

Restrict, control, monitor and audit privileged account access and use

Exploitation of privileged accounts is a common and easy vector for intrusion into any system. To make matters worse many systems have an ‘all or nothing’ configuration of privileged accounts. The most common example is the ‘Domain Administrators’ group in Microsoft Active Directory where members of the group are able to perform any action on any object or device in the domain with little-to-no audit or oversight.

The people who feed and water the systems should only elevate their access to a privileged state when they are required to do so and only as part of a controlled and audited event. A few simple rules and approaches can help realise this.

Operations staff are users too, therefore their accounts are just normal user accounts and confer no special access or privileges at any time. This approach serves as an important reminder to the operations staff that a conscious choice and action the part of the operator to elevate their access, it pushes back on the operators inclination to think ‘oh i’ll just quickly tweak this small thing’ and possibly leave something in an open state or worse still have a broad, unintended side effect. Remember, with great power comes great responsibility.

Privileged groups and roles are always empty. If the system has a role-based access control mechanism and the roles and groups with elevated privileges are empty then there are no individual user accounts to leverage to gain elevated access.

Privileged group and role memberships are controlled by policy. The IDAM system shouldn’t govern what users are members of what roles. A policy control system (in AD that’s Group Policy for example) should be used to define which accounts are members of which privileged groups. Doing this ensures that even if an attacker is able to enact a change in the IDAM system that there is another layer of control and audit which can revert the change quickly to the desired state.

Changes to privileged groups and roles are audited, monitored and alarmed. This is a critical capability to realise. The operations teams (both infra and sec) should maintain situational awareness of use of privileged actions and changes. This means that everyone knows when a privileged action is scheduled to occur so that when it occurs unexpectedly alarms can be raised and investigations commence.

Businesses insist on a ‘separation of powers’ approach to procurement and purchasing, privileged access to systems should be no different.

Use 2FA/MFA authentication

Password sharing between systems and storage of passwords in weak or reversible forms is the biggest single threat to the safety of credential information in any system. For public Internet accessible systems the viability of the username/password pair as a secure method of access control is no longer tenable. Better security of user authentication is required.

Enter two-factor authentication (2FA) or multi-factor authentication (MFA). This capability adds a third factor to the user authentication process and better yet it is something that is not easily shared and is only valid for a short period of time. Attackers can attempt to brute-force their way into an account forever and without the token will never succeed. Better yet, attempted logons without 2FA or MFA can be used to trigger alarms and prompt further investigations by ops and sec ops.

Attach the 2FA/MFA to a privileged account request or action and a strong protection against compromise of elevated privileges is realised.

Backup data and offline storage

This mitigation ensures that backup data is captured and stored in a manner that makes the data impervious to ransomware and other data loss type intrusions. Data backup is a core service component of any IT system, however, in recent years, as the incidents of ransomware has grown, stories have emerged of systems that suffered a ransomware intrusion which also managed to reach data backup systems. This has meant that businesses have not been able to restore their data because the backups are also encrypted. In some of these cases business have paid large ransoms or gone bust. Payment of the ransom is also no guarantee that that attacker will release the decryption keys to you.

Storing backup data in an offline manner is considered an ageing practice now however it is an effective mitigation for ransomware and other malicious data loss scenarios because it ensures that backup data is not subject to this type of intrusion.

In cases where offline storage is undesirable or difficult, then implement strong control and audit of backup account and system access. Treat backup access as a privileged action and ensure that backup data cannot be accessed without using 2FA or MFA. Consider a three tiered backup data storage approach where recent backup data is stored online or near-online and older colder backup data IS stored offline.

Backup data is the last line of defence against ransomware, ensure your organisation and teams are well geared and equipped to rely on it when things go badly wrong.

Whitelisting, macros and application hardening

The essential eight recommends three other strategies for mitigation which are worth mentioning since they aren’t strictly recommended for businesses here.

These three mitigations have important value in the effort to prevent and limit infosec incidents in any organisation and must not be dismissed out of hand. Their important to private business in this article is diminished for a few different reasons.


Application (or process) whitelisting is a very large, complex and onerous mitigation. Imagine if you will a haystack full of needles. Each needle is a different length, diameter and type of metal. Now build a sieve which will filter all the hay and needles and ensure that only a single needle remains in the sieve. A very difficult, complex and time consuming activity.

Whitelisting has a place and there are multiple ways to achieve it, however there are few environments where the cost or complexity risks make whitelisting a must have.

Office macros

It is often said that businesses run on spreadsheets and Microsoft Excel is no exception. The macro capability that is baked into all 32 bit versions of Microsoft Office was one of the first exploit vectors and remains in use today.

Microsoft has made changes to the default security posture of office when it comes to macros however the functionality remains on by default and this is what intruders rely on.

For organisations that don’t use Office macros they are very easy to disable via Group Policy and should be mitigated this way. Better yet, deploy 64 bit Microsoft Office which doesn’t support Office macros at all.

Application hardening

It’s unclear why the blocking of Adobe Flash and Java is referred to as application hardening. Both these technologies are known exploit vectors particularly Flash and sometimes through website advertising networks.

Block Flash and Java at the perimeter of your networks. When done well, you will be shocked to see how much faster webpages load when all those advertising frames aren’t rendered. As another side bonus you will save your Internet bandwidth as well.


If you have gotten this far then I congratulate you. Push on and review the additional information available from ASD on each of these topics.



mpp files stored in SharePoint open read only in Project Client | Microsoft Office Sharepoint


Yay. I needed to write up a quick project plan for an upcoming engagement. I refuse to do project plans in Excel on principle.

Installed Project 2013 on my Windows 10 VM. Applied pending Windows update. Created plan. Saved to SharePoint Online. Closed Project.

Went and did something else.

Came back to make adjustments to the plan. Everytime I opened the plan from SP in Project it would open as read-only.

This is a known issue and the KB below will help you.

Ill drop Project 2016 on there tomorrow and see if its O365 integration is any saner. In the meantime the patch below worked around the problem.


Source: mpp files stored in SharePoint open read only in Project Client | Microsoft Office Sharepoint