Requiring Periodic Password Changes Is (Probably) Still A Good Idea

There is growing momentum behind dropping the periodic password expiration requirement – generally 90 days.  The idea first gained widespread credibility when NIST updated SP 800-63 way back in 2017, advising against requiring password expiration policies.  In recent times, most of the security thought leaders seem to consider password change policies to be an outdated, cyber horse and buggy remnant of times gone by.  This week, Microsoft releases a blog post stating their intention to drop password the expiration requirement from the Windows 10 and Windows Server security baseline.

In concept, I agree with this guidance.  Troy Hunt gives a great enumeration of the many reasons here.  In practice, I have grave concerns with this approach.  I do want to make it clear that I think everyone should be using a password manager with strong, unique passwords for each service, and even better, using multi-factor authentication everywhere its supported.  If this were the default condition, I would have no objections to dropping password expiration requirements.  But alas, this is not the world we live in.

People are mentally lazy.  I don’t mean this in a derogatory way; I mean that our brains are hard wired to minimize the amount of effort we apply to any given task.  The net impact of dropping password expiration requirements is that some number of staff will adopt a single long and complex password that they will use everywhere.  As we have seen repeatedly and consistently over many years, internet-based services are a) terrible at storing passwords in a secure manner; and b) terrible at keeping their authentication database secure.  This inevitably sets up a situation where I create a complex password for work, with no intention or requirement to ever change it, then also use it on my favorite horoscope website (everyone needs a methodology for making security related decisions, right?).  My horoscope website is compromised and now my work password that never changes (probably along with my work email address) is out in the wild.

My main objection to dropping password expiration requirements is that it enables employees to use a “work” password everywhere, whereas it is generally infeasible to do so with a password expiration in place.  I have many other tangentially related concerns, many of which people who work in incident response will recognize: adversaries in a network are able to collect non-expiring credentials from obscure places, like old backups and documentation, and so on.  In my experience, these passwords are often already a problem because people will simply iterate some prepended or appended element of passwords (Password1, Password2, etc), which can often be easily guessed by a targeted intruder.

Like many good ideas (looking at you, Active Directory), the benefits arise from a certain ecosystem being in place.  Organizations often want to embrace the aspects of a new paradigm that they like, but not the parts that are inconvenient or expensive (see: my disdain for Active Directory).  There are ways to help mitigate this concern, such as periodically  comparing recently breached passwords to those used by employees and immediately disabling or changing any matches found.  However, much like properly securing Active Directory, nearly no one does this, instead taking the “quick win” of disabling password expiration because that is now industry best practice.

 

Thank you and My #infosec Hopes For 2019

I already published my ground-breaking infosec predictions for 2019, but I also want to say thank you to all the great people that I’ve had the privilege to work with and have met, even if only through social media.  I appreciate every one of you.

One of the things that I’ve come to learn about human behavior is that we tend to more consistently accomplish our goals if we make a commitment to others.  Here are the items I want to accomplish, or at least get started, in 2019:

  1. Reinvigorate the Defensive Security Podcast.  I’ve let myself become increasingly busy and the frequency of new episodes has suffered as a result.
  2. Develop my interest and passion about the intersection of behavioral economics/behavioral psychology and information security into something meaningful: a blog, a podcast, a book.  I don’t know what form this will take yet, but I believe there is a significant opportunity to advance the field of information security.
  3. Grow my previous efforts to help people enter the information security field.  I don’t know what form this will take yet, but in the past I’ve provided e-books and tried to match people looking for work with companies looking for employees, mostly via Twitter.
  4. Learn much more about cloud computing, SDN, and how to incorporate security and resiliency into these environments, as well as how to capitalize on the new capabilities these environments provide for security and resiliency.
  5. Develop an idea I have had around “componentizing” IT infrastructure designs, in a similar manner to “design patterns” for software development.  I wrote a bit about this in the past.  I don’t know what form this will take – maybe a wiki or something similar.
  6. Deliver a presentation, without completely panicking, at a conference.

Happy New Year, my friends!

Predictions for 2019

This is the time of year where all security vendors take stock of what they need to sell in the coming months and produce a litany of terrifying predictions that can be thwarted if you, the hapless victim, will start writing purchase orders.  While I don’t have anything to sell you here at infosec.engineering, I have been working feverishly for the past several months on really insightful and grand prediction for 2019.  My hope is that this prediction will help organizations around the world to better prioritize their security spending and resources.  After all, what good is reading a prediction (and all the attendant bloviation) if it can’t help you in some what?  Well, on with the show:

Jerry’s cyber security prediction for 2019:

Tumisu / Pixabay

2019 will pretty much be like 2018.

Now, I know that you are probably reeling here, mentally recounting how this knowledge impacts your organization’s capital and hiring plans for 2019 and what you would have done differently had you known this a few months ago, but there is always time for course corrections.

The controls and processes that were important way back in 2018 continue to be important in 2019, and possibly even more so.

Strive to design robust IT environments supplemented by appropriate controls and monitoring.  Hire and/or develop people who know what that means.  Stay abreast of trends and test the effectiveness of your controls considering those trends and respond accordingly.  Or don’t: I can always use new material to discuss on the Defensive Security Podcast.

NCSAM Day 23: Act Ethically

Short one today – migraine.

As security professionals, we are often put into difficult positions and face difficult choices. Sometimes the ethical path is uncomfortable or unpleasant.  We need to hold ourselves to a high standard of ethics and honesty.  We often have access to sensitive business information that can benefit us personally.  A recent example of how this can go wrong are the criminal cases involving Equifax IT staff trading Equifax stock using non-public information about their massive data breach prior to the breach being announced.

NCSAM Day 21: Keep Up-To-Date with Technology and IT Trends

Corporate IT seems to be evolving at an ever increasing pace.  As security professionals who want to stay relevant and employed, it’s our duty to understand these changes.  For example, most organizations are in the process of migrating IT to the cloud.  However, as I’ve previously written, the cloud is not a magical place and requires an updated set of security skills and approaches.

I have no affiliation with O’Reilly, but my experience is that their Safari Books Online is about the most economical resource to help me stay current.  It’s about $300 per year, but provides access to many thousands of technical books, video tutorials, and conference recordings.  Videos of conferences such as Velocity, Strata, Fluent, The Artificial Intelligence Conference, OSCON, and others are a great way to get a view of the landscape, and you’ll find plenty of books to explore any particular area more deeply.

Another good place to get information is security conference videos.  Adrian Crenshaw maintains an extensive list of recorded conference presentations on his website here: http://www.irongeek.com/

Anyone that has been in the IT security field for a while intuitively understands that there are concepts that apply regardless of technology, and that is certainly true, however understanding the technological and business shifts in the use of technology is necessary for us to stay relevant to our organizations.  In this industry, we cannot afford to stand still.  We must keep learning and growing, otherwise we will become marginalized and ignored in our organizations.

NCSAM Day 20: Learn to Write Well

I spent the first nineteen days of National Cyber Security Awareness Month giving some hopefully useful ideas on improving security in your organization.  I’m going to spend the remaining days writing about us as IT and security professionals.

To implement change, we need to be able to influence others, such as our managers, our executives, our CEO, or our board of directors.  Without the ability to communicate and influence change, our good ideas for improving security remain just that: ideas.

The way we write is often the first thing people learn about us.  It represents the first impression of those we need to communicate with.  The ideas we are trying to advance are inextricably linked in the minds of our readers with the way the message is presented.  Based on what I’ve seen throughout my career, writing is a challenge for many people and I strongly suspect many good ideas fell victim to overly casual writing and a herd of punctuation and spelling mistakes.

Writing is a skill that takes practice.  Not just practice, but “deliberate practice” as Anders Ericsson describes in his book “Peak: Secrets from the New Science of Expertise”.   Candidly, improving my ability to write is one of the main reasons I started the infosec.engineering blog and in particular, why I challenged myself to write a post every day for NCSAM.

In summary, focus on developing your writing ability.  You will benefit professionally, and your organization will benefit more from your ideas.

NCSAM Day 19: The Importance of Learning Offensive Tactics

Over the years, I’ve worked on investigating and cleaning up many breaches, and in nearly every single instance, the IT team that designed and managed the environment had no concept that their system could be exploited in the manner it was.  Another commonality is that nearly all of those breaches resulted from a chain of weaknesses, some of which were consciously “accepted”.  I argue that it is difficult to design a system resilient to attack if one does not know the tactics adversaries use, and it is equally difficult to assess risks without understanding how controls help block adversarial techniques.

For National Cyber Security Awareness Month, my hope is that people responsible for designing and assessing IT environment take time to learn about adversarial tools and techniques to design more robust environments and processes.  This is, unfortunately, not a one-time event, though: techniques change over time, and we need to keep up with the latest trends.

The downside, I suppose, to this advice is that red team can be quite addictive and we’ll lose many competent IT people to the pen test puppy mill.

NCSAM Day 18: Protect Administrative Interfaces

Zero trust networks are quickly becoming all the rage in the IT world.  Building proper defenses into each endpoint and relying on strong authentication schemes seems intuitively right.  I’ve had several recent discussions with smart people about how dull the old world of network-based firewalls which grant implicit permissions based on the network location of a particular device (i.e., inside vs. outside the firewall), which is just another way of saying that we should move toward zero trust.

But all this presumes that the “endpoints” can be secured.  Many pieces of IT infrastructure, including switches, servers, firewalls, and many other devices contain administrative interfaces that have security that is on par with, or slightly worse than, the average home router.  In the past few years, we’ve seen many, many problems with the lights-out management interfaces for various servers; we’ve seen a (so far) non-stop parade of authentication bypass/hardcoded passwords in Cisco devices; and we’ve seen many other devices using various badly configured or exploitable services running on these interfaces, like dropbear, libssh, and others.

These interfaces should NOT be exposed to untrusted networks.  That, sadly, means that we need to continue on with architecting, at least to some extent, well thought out networks.

The concept of a “management network” is not new.  I was first introduced to the concept over 20 years ago, and I suspect the idea was already old by that point.  Remember that a management network, by definition, is a concentration of sensitive interfaces and user sessions that have administrative privileges.  A lot has been written about the design of management networks by people much smarter than I am, but I’ll give some ideas/observations here:

  1. Ensure that only authorized people and devices are able to connect to the management network
  2. Monitor activities on the management network for indications of unauthorized devices or users
  3. Keep the number of devices on the management network as small as possible – A one to one relationship would be optimal, but often impractical

NCSAM Day 16: Ransomware Happens

Sometimes, despite our best efforts, ransomware will successfully invade our systems.  The need for good back ups should be well known by now, but here are a few recommendations:

  • Several organizations impacted by the likes of SAMSAM have opted to pay the ransom to recover their data, despite having good backups. This is apparently happening because the time and cost to restore all the impacted systems and data from backup is substantially higher than the cost of the ransom.   I previously wrote about why it’s a bad idea to simply clean an infected or compromised system and paying the ransom to get back to operations faster is basically doing just that.  I argue that an organization that is tempted to pay the ransom in such a case probably did not properly assess the RTO and RPO that were needed when designing and implementing its recovery program.
  • Be aware that some “backup” schemes use real time or near real time replication between systems in remote sites. Ransomware-encrypted files will be replicated to the backup location nearly instantaneously.  Remember to make backups or take snapshots if you’re using such a recovery scheme.
  • This shouldn’t have to be said, but you (probably) don’t have a backup if you haven’t tested your backup. Test them.
  • Over time, we will likely see a shift to injecting techniques that render backups useless to help force ransom payment.
  • One of the insidious aspects of some ransomware like SAMSAM is that is can effectively take out all systems on a network. Consider your ability to initiate recovery if all of your administrators have locked up workstations and your (ugh) Sharepoint repository of recovery plans are all encrypted.
  • I previously wrote a longer post on how to prevent ransomware infections.

 

NCSAM Day 15: RDPmageddon

Remote Desktop Protocol, RDP, is becoming a common entry point for bad actors, including many POS terminal breaches, and the main delivery method for enterprise-grade ransomware, like SAMSAM.  An underground economy has developed around finding and then selling credentials to access various organizations through RDP.

Though it is a legitimate tool for administering Windows systems remotely, RDP should never be exposed directly to the internet.  Firewalls should be configured to disallow RDP access from Internet sources, and systems that run RDP must not permit accounts with default or weak passwords.

Use a service like Shodan to scan your organization’s address ranges to identify RDP services exposed to the Internet.  Workstations should be configured via GPO to disable RDP, enabling it only by exception.