Who is responsible for patching?

Midweek rant.

How many times have conversations along the lines of;

‘we are waiting for security to tell us what to patch’

occurred?

Why do teams responsible for running and maintaining systems persist in making patching a security issue?

I would challenge this and go as far as to say it is fundamentally wrong.

Patching / maintenance / updating systems must been seen as a core part of running a solution.

No solution should ever be deployed into a production environment without a clear ownership and agreed processes for maintaining it.

The role of the security team should be to provide assurance that the environment is being patched etc. according to the agreed processes.

Simple.

This would change your weekly / monthly patching / vulnerability management meetings from ‘here are all the patches that are past due and must be applied’ to ‘great job guys, 90% of patches applied lets discuss the few outliers’.

Also what happens with all the non security patches in these environments? Are they ever applied? how are systems kept up to date?

So – Maintain you systems. Patch them.  Keep them up to date. Let security provide assurance that this is happening.  Simple.

This approach also allows people to spend a lot more time working on the hard security problems rather than spending half their life talking about why patching has not happened!

A slightly blunt one, but I strongly believe this move in responsibility and accountability must occur if the patching crisis is ever to be resolved.

The next post will be back to the range of topics I have been discussing recently.

K

 

Application Security is more than development security

Last week I wrote about the OWASP top 10, and the main steps that I think make up an application / development security programme.  This can be found here; http://www.kevinfielder.co.uk/security/why-does-the-owasp-top-10-never-change/

Following from this I want to discuss the security of your applications is actually so much more than the secure development and assurance lifecycle along with developer training.

Doing all of the things I previously mentioned, tailored for your environment, will ensure you have as secure an application as is reasonable possible when compared to your threat landscape and risk tolerance.  However the actual application / code is only part of the security story.

So what next? Does that mean your application is secure?  Does it mean it is secure in all environments?

I am a strong believer in the principle of defence in depth.  Even if you believe your application to be completely secure under any circumstances, I would always recommend having multiple layers of defence.  Some of these layers will be independent security tolling, and some will be within the application itself e.g. security SDKs that can be incorporated invisibly into your application.

The below list will highlight a few of the areas you should consider in order to protect your applications and the data they hold about your business and it’s customers.   The list focusses on technical security measures rather than processes, which are a completely different topic.

Application Firewalling

A ‘normal’ firewall is great for providing very fast and robust IP and port based filtering.  However it has no understanding of what should be sent to the permitted IP addresses and ports.

An application firewall understands the traffic your application should receive.  The most typical application firewall is the WAF (Web Application Firewall), Database firewalls also exist.  Web application firewalls will automatically be able to protect your web applications from known attacks like SQL injection.

A further benefit is that specific rules can be created to protect against specific vulnerabilities that may be discovered by your code analysis tools or pen tests.  This can aid speed to market by protecting your application while a fix is worked on.

The key thing here is that the WAF (or DB firewall etc.) will sit between the users of the system and the application, ‘proxying’ all the connections and alerting on or filtering out malicious traffic before it even gets to the application.

Logging

While this may seem outside of the application, and indeed the SIEM / log monitoring part is, logging the right information is critical.  Unfortunately it is often overlooked.

Do all of your applications log enough information about enough events to provide real security value?  This means a lot more than just things like logon / logoff.  Any ‘security’ interesting activity such as administrative activity, user creation, permissions changes should be logged.  Also consider user activity, so that there is a clear audit trail for whom undertook which actions.

Just as importantly is this in a format that can be ingested and analysed by your security log monitoring systems?  Ideally if you have multiple applications your organisation develops you should have a standard logging format, this would be facilitated by creating / using a common logging API for all applications.

As a final thought on logging don’t forget that for the security team to be able to provide useful alerting from the logs, they need to understand what good and bad look like to your applications.

Server Application control

While perhaps not strictly ‘application’ security, a key protection that rarely seems to be implemented is strong application white listing and application controls.   I mention these as I think they make a key part of the overall protection and I had omitted to cover them in detail previously.  Servers should have a pretty static application lists so the overhead of running whitelisting controls should not be excessive once in place.  The other benefit of these solutions is they also understand how many applications should work, so they can prevent even compromised commercial applications from misbehaving.  This should be seen as a key protection for any high risk application servers in your environment, especially those hosting internet facing applications.

Mobile application and device protection / analysis

This is one of my current areas of interest.  How do we protect mobile applications that will be installed on fundamentally untrusted devices?  This can apply so normal Windows / Mac apps as well – see below.

So your application is ‘secure’.. Some questions to get you thinking about the environment a mobile application will run in;

  • How secure is it if the mobile device is compromised and there is key logging software on the device, or man in the middle software that changes the users inputs before sending them to the server etc?
  • How do your servers know if the application talking to them is your application or an exact copy of your application that has malware added?
  • How does your application stay up to date to detect the latest rooting / jailbreak methods and malware?
  • Does the behaviour within the application look like a human user, a bot, someone remote controlling it?

It is to enable us to answer these questions, and more, where mobile application security solutions come into play.  I’ll not cover these in detail as there will be an upcoming post very shortly to cover this specific point in more detail.  Suffice to say if you run mobile apps that handle any sensitive data or transactions etc. this an area you need to be all over.  This also has multiple wider benefits highlighted further down this post.

Remote host security (if you supply an application to them)

This is a similar idea to the mobile security one.  With the continuing malware epidemic across Windows, and the increasing prevalence of malware on Mac and Linux protecting your applications on remote machines should be investigated.  Again, this is especially relevant if you supply an application that processes sensitive data of any sort.

On one hand you could argue that the security of the end point is your customers responsibility, and you would be correct.  However given the challenges faced by most people, especially in the personal or SME markets is this a realistic stance to take?

Given the ease with which you can integrate a host protection SDK from one of the many vendors out there, I would certainly recommend looking into this option, especially if you charge your customers for the service.

Remote browser security

This is where we look at options for securing, or at least monitoring the remote browsers that connect to your web applications whether from mobile or more traditional desktop devices.  This is the area where we have least control, as we are not installing anything on the remote device.

However all is not lost, we can insert various security measures into the page to look for potential browser issues, ID the browser and machine, and perform cool things like in field encryption.

As with the mobile security solution I would recommend that you investigate commercial options here as they will keep themselves up to date against evolving threats and also provide a wide range of added functionality like risk scoring, automated blocking etc.

Also as with the mobile security I’ll write about this in more detail, as in my experience this is overlooked by the vast majority of organisations.

Authentication

This one shouldn’t need any introduction.  In this case what I am referring to is the confirming to an appropriate level that a users is who they attest to be.  There are however many pitfalls around authenticating users of a system.  Obviously ensuring someone is who they say they are is key to securing your applications and their users.

The added benefits of supporting better authentication than passwords are much broader than just being more secure.  You can offer a much better journey for your users, with reduced or no friction for many activities.  You can also gain a lot of useful data as many authentication solutions collect extensive data around the user and device to enable risk based authentication.

Don’t forget, how you do authentication is also incredibly visible to your users and one of the first ways they interact with you every time you use the application.  So this is a great opportunity to both provide a great impression and to highlight that you take security seriously right from the ‘front door’.

Authentication is another area I will be covering in more detail as it is critical we move away from passwords.

Further Benefits

Consider the multiple wider benefits of remote security solutions and authentication;

  • More secure customers = better security for you.
  • Offering security = differentiation and potentially something you can charge for.
  • Data Data Data – the more data you have about your customers and their behaviours, the more interesting analytics you can perform.

These benefits all apply to mobile application security solutions, remote host security, remote browser security and to some extent new authentication solutions.  I briefly explored some of these in my earlier ‘Extending the Perimeter’ article, and will expand further on these in following posts.

Conclusion

Don’t forget that this is all in addition to all the ‘standard’ security stuff you must be doing anyway such as Firewalls, IDS/IPS, anti malware / host security, standard hardened builds, vulnerability scanning and patching etc.

If you have been following my last few posts, you should have a good idea of the basics required for general and application security, plus a few more advanced thoughts from this post.  Once you have these security basics in place,  you can then start looking at the even more interesting stuff!  This includes network and application behavioural monitoring and big data analytics.

As always, do the ‘basics brilliantly’ before spending too much time on more advanced security.  Malicious individuals and groups will tend to go for the low hanging fruit.  Even if they are specifically targeting you, they will look for the easiest way in.  No amount of advanced, behavioural monitoring will protect you if you’re hosting unpatched servers on the internet with single factor authentication and simple passwords!

More next week!

K

Why does the OWASP top 10 never change?

Or very rarely?

Subtext, how should we work to create more secure applications?

The OWASP top to remains largely unchanged over long periods of time.  We still see high profile breaches like Talk Talk caused by easy to protect against application attacks.  These fact imply many organisations are still failing to do ‘application security’ properly.

So why is application / development security so hard?  OR is it?

I think application security has historically had similar problems to other areas of security.  It is not seen as a business imperative, so business needs, new features, meeting client requests etc. all supersede security requirements in the priority list.

For many of us this is clearly not news.  However, given the number of incidents that still occur, it is clearly not a problem that has been solved.

For me solving this falls into 3 key areas;

  • Board level buy in for security, and specifically security throughout the development lifecycle – SDLC (Software / Systems Development Lifecycle).  This will ensure there is support for the costs and time associated with delivering a secure development programme.
  • Buy-in from the development teams.  Work with them to ensure they understand the reasons for, and benefits of secure development.
  • Making security part of the SDLC, by ensuring that the relevant tasks and processes are embedded as part of the standard lifecycle.  This will also ensure they are audited as part of that process.

I’ve spoken about board / exec by in for security before, and will do again.  There will also be another post in this series covering developer buy in as that is key to the process being successful.

The rest of this post will cover the areas that I think need to be covered in through the process in order to ensure the development process is as secure as possible.

Where these steps fall, how they are implemented, and how they are checked / monitored will vary from organisation to organisation.  They will also depend on the development processes in place such as Waterfall and Agile variants.

At a high level, these steps are;

  1. Requirements including security requirements
  2. Secure designs
  3. Threat modelling
  4. Static code analysis
  5. Peer code review – focus on quality and maintainability not just ‘pure’ security
  6. Dynamic application analysis / web application scanning
  7. Penetration testing
  8. Associated processes – found flaws are fixed at each stage of the process
  9. Clear risk assessment and ownership processes
  10. Developer Training

 

Requirements, including security requirements.

Any project must have some requirements.  These are what enable us to answer the question ‘what problem am I solving?’.  This also applies to BAU (Business As Usual) type development that may not fall under the project processes.

These requirements need to include the non-functional areas as well, of which security is one.  Security requirements should be as standardised as as much as possible to minimise the effort, and tailored as part of any project or work initiation phase.  To support this, ensure your application security team is closely embedded with the project teams, business analysts and developers.

Secure Designs

While this is more of a statement than process, I have included it to highlight that security teams need to be involved throughout the design process.  I would also recommend that security should be an approver of system and application designs.  This will ensure that meet security policies and requirements as well as meeting secure design principles.

Threat Modelling

This is the process of reviewing a system and assessing any potential threats to it, along with how to counter those threats.  The earlier in the process this can be accomplished the better as it allows the designers and developers to work with the potential threats in mind.  Although either an existing system, or at least a high level design is required to make this worthwhile.

I am personally a huge fan of threat modelling as it has multiple benefits for relatively low cost / effort;

  • More secure designs and development as the teams working on the solution will have a better understanding of the threats, and how to counter them.
  • A better understanding of the system, one of the artefacts from threat modelling is the DFD (Data Flow Diagram).  How many systems in your organisation have have detailed DFDs?  This fills that gap.
  • Under the radar security awareness training.  Without labelling it training, the security team gets to spend a decent amount of time with the design and development teams talking about threats to a system, the consequences if these threats are realised and how to protect against them.

Static Code Analysis

This is the use of a code analysis tool the performs automated scanning of the code and / or binaries for potential security weaknesses.  Good tools also provide remediation guidance for the discovered issues and a workflow for assigning the issues and documenting how it will be remediated or mitigated if your don’t already have a tool for this.

These tools will integrate with various development environments and source repositories, along with different development processes.  If you are not already using one I would recommend performing an analysis of the key players in the market to assess the best fit for your environment.

Peer code review

This is the process of ensuring different developers assess each others work.  This should include cross team assessments with a strong focus on code quality and maintainability as well as security.

Encouraging this process to be as open as possible, to enable open debate about the best way to code will definitely be beneficial.

While code quality may not be strictly a security concern in the traditional sense, the better written, commented and maintainable code is, the easier it will be to maintain the applications security over the longer term.  This is especially true as it is developed and worked on by multiple people and teams.

Dynamic Application Analysis / Web Application Scanning

Similar to the static scanning, this will be an automated process, carried out using a scanning tool.  This is the process of assessing a running application for security vulnerabilities.  These usually focus on areas of user interaction such as web pages so will not be suitable for all systems.

The need for a running system means these scans fit later in the process than the static scans, and usually fit well through the testing phase of any project / development work.

It should be noted that while these are more effort than static scanning, they should be considered especially for larger or more critical systems as they will find issues earlier and at a lower cost than pen testing, thus ensuring less issues are found later in the process.

Penetration Testing

This is the process of dedicated professionals, usually from a specialist third party attempting to ‘hack’ the solution.  This is usually the final check from a security perspective that a piece of development or an application is secure enough to go live.

Due to the costs and efforts involved it is likely that you will want to haver a clear process in place for when and how often pen tests are required.  Depending on your industry there may also be minimum regulatory requirements around how often systems are pen tested.

Associated processes

I have included this as a catch all to highlight that all of the above processes need to have agreed and working feed back loops to ensure the items they identify are assessed and remediation agreed.

Risk Assessment and Ownership process

Following the above point, and discovered vulnerabilities that cannot be fixed or mitigated will lead to a risk to the organisation.  This must be formally assessed in terms of the level of risk, and then accepted for an agreed period by an appropriately senior business owner.  The risk process is an entire topic of it’s own!

Developer Training

I was not sure whether to put this at the start or end of the list as it must be an ongoing process outside of any specific project or development work.  As well as ensuring that your developers have approbate levels of secure coding training, this should be seen as a key part of your engagement with the developers and getting their buy-in for secure development.

Depending upon the size of your organisation I would recommend a combination of on line computer based training (with a programme to increase the skill / knowledge on the courses over time and dependant on the experience of the developers), workshops and presentations from external companies, including pen testers.  For larger organisations secure development forums and ‘conferences’ could also be considered.

 

While nothing is completely secure, especially as complexity increases, if you follow these steps as part of the process you will end up with applications that are definitely not the ‘low hanging fruit’.  This will reduce your risk of any application related breach.  In addition it will mean that should you have a breach your organisation will honestly be able to say that they had done what they could to ensure secure applications, and the protection of the data you hold.

As final thoughts for today’s post, do not take these in isolation, this only covers the application part of your security, all the other key areas from network security to JML (Joiners, Movers, Leavers) processes must be in place to ensure an appropriately secure organisation.

K

 

 

 

The password is dead, long live the password?

There have been many reports of the death of the password.

However the password remains the most common authentication method by far.  Indeed, many apparently forward looking organisations still rely on them for their staff and customers security.

Given the multitude of well published breaches caused by password hacks, and the number of stolen password databases it would seem like a no brainer for organisations to move to more secure authentication methods.

Indeed, as this article from a couple of years ago demonstrates clearly passwords are not very hard to crack;

http://www.wired.co.uk/news/archive/2013-05/28/password-cracking

Even if you think your password is especially complex..

Interestingly it seems many ‘free’ services such as Yahoo and Gmail are actually leading the way and trialling more secure solutions even if they are not as slick as they potentially could be.  So we have a situation where your free service offers you more secure authentication than many of the paid services you or your organisation may use.

If you have services that only offer passwords as an authentication, or if you as an organisation still only offer this, then please adhere to 3 simple pieces of advice.  And please make the effort to educate your colleagues and customers!

  1. Have the passphrase mindset, not password.  Length beats complexity so use long, but easy for you to remember passphrases.
  2. Use a variety of passphrases for different sites, so if one is compromised your other accounts are not
  3. Change them reasonably frequently, say every 90 days.
  4. Oh and as a bonus, don’t ever share them!

So while everyone seems to agree passwords are pretty poor from a security perspective, very few organisations are really working to move away from them in the near term.

Why is this?  The reasons I can think of are;

  • They are free and easy
  • Everyone sort of understands them
    • I say sort of because we know what they are but provably fail to create ones that are difficult to crack, we re-use them extensively etc.
  • While the broader public read about how bad they are, they still don’t really push for something better.
    • Or they just accept them as most companies don’t offer anything better so what choice do they have?
  • More secure solutions involve change
    • People and organisations are often scared of change
    • What will our customers think?
    • Will it be difficult?
  • More secure solutions will involve cost
    • Implementation
    • Licenses
    • Support / management

However I think now really is the time to start moving on this.

Ask yourself;

  • Does your organisation want to be in the news as the next one suffering a breach relating to passwords, whether cracked, social engineered or stolen?
  • Do you want to lag behind competitors and ‘free’ services as they start offering more secure authentication solutions?

In terms of offering more advanced and secure authentication solutions, there are many potential benefits to your organisation and its customers including;

  • Differentiation (for a time)
    • Get ahead of your competitors, be seen as a technical and security leader by offering very public security enhancements.
    • This will also help your reputation as an organisation that takes security seriously.
  • Less hacked / breached accounts
  • Improved security for you and your customers
    • Better security for your customers = better security for you.
    • It is also extremely likely that what ever solution you implement can be rolled our to employees as well as customers.
  • Improved analytics and understanding of your customer environment
    • Most authentication solutions are able to collect a lot of data around both the behaviour of users, and their environment (browser and device information).
    • This is especially true of those that support risk based authentication.
    • If your organisation collects data into a big data platform, then this data can further enrich that, enabling greater analysis of user behaviour, what good / bad looks like etc. (more on this in a later post).
  • Better customer experience
    • Risk and policy based authentication enables decisions to be made based on things like the users historical behaviour, device knowledge, and the action within the application they are performing.
    • This means that for lower risk, known activities from known devices the users interaction with the system may be entirely friction free for them.  ‘Step-up’ authentication can be applied when they step outside of normal behaviour, or want to perform higher risk / administrative type activities.
  • Staying ahead of regulatory requirements
    • Increasingly regulators are starting to require ‘strong authentication’ for customer interactions with an organisations systems.  This is especially true in areas such as banking and payments.
    • Implementing solutions now will save you a rush to meet regulatory requirements in the near future.

I hope from the above that my position on this is clear.. It is time to move away from relying on passwords, and there are huge benefits from doing so.

It would be great to hear from you and to get an idea of how many organisations are genuinely planning to implement more secure and innovative authentication solutions vs. those who frankly have their heads in the sand.

K

 

 

2016 Resolutions. The detail..

As promised, this follow up post will outline what I mean by each of the ‘resolutions’ I highlighted.

These were;

  1. Patch.  Everything.  On time.
  2. Protect your hosts.  Do application whitelisting.
  3. No admin rights for anyone who can access production data.
    1. No one with admin rights can access data.
  4. Role Based Access.
  5. Segregate your networks.
  6. If you create code, do solid code assurance.
  7. Test and Audit.

 

1. Patch.  Everything.  On time.

Sounds simple right?  It should be, but it seems it isn’t in many companies.  From my experience there seem to be 2 main drivers for so many companies failing this most basic of maintenance tasks;

  • Systems that must have almost 100% uptime, with no, or ill defined patching windows and processes.  This goes hand in hand with these solutions being incorrectly designed, if a system must always be ‘up’, design it in such a way that components can be taken out of service to be patched and maintained (or indeed if they fail).
  • Incorrect ownership and drivers for the patching process.  In many organisations it seems to be the security team who drive the need to apply ‘security’ patches.  This needs to be turned around.  Any system in production must be patched and maintained as part of BAU.  Systems / solutions should never be handed over into production without clear ownership and agreed processes for maintaining them, this must include patching.  Security then become an assurance function for this and their scans / checks confirm that the process is being correctly followed, plus of course highlighting any gaps.

If you see these issues in your organisation, make 2016 the year you address them, don’t be the next business in the headlines that is hacked due to systems that have not been patched for months!

2. Protect your hosts. Do application whitelisting.

With the ever more porous nature of our networks and perimeters, coupled with the insider threat and phishing etc. protecting our hosts is becoming ever more critical.

AV (Anti Virus / Malware) is not dead, but it also clearly is not enough on it’s own.  Indeed you will struggle to find any host protection product that only does AV these days.  Ensure all your hosts, both servers and user end points are running a solid, up to date and centrally managed host protection solution (or solutions) providing anti malware, host IPS (Intrusion Prevention System), host fire-walling and ideally FIM (File Integrity Monitoring).

I’m gradually trying to change peoples language from AV / Anti Malware to Host Protection as I think this covers both the requirement, and many of the solutions far better.

In addition to this I would strongly recommend the use of an application whitelisting solution, as this can provide a key defence in preventing any unapproved (or malicious) software from running.  As well as preventing malware, these solutions have the added benefit of helping to maintain a known environment, running only known and approved software.

3. No admin rights for anyone who can access production data.  No one with admin rights can access data.

This is something I am currently championing as a great way to reduce the risk to your organisations data.

This may be harder for very small organisations, but for medium and larger ones, think about the different roles your teams have.

How many people who need to access key data, e.g. via production applications, need to have administrative rights on their end user systems, or on the production systems?

Conversely, how many of the system administrators who maintain systems and databases etc. need access to the actual production data in order to perform their duties?

One of the most common ways malware gets a hold is via users with administrative privileges.  So if we prevent any user with these elevated privileges from having access to data, if they or their systems are compromised, the risk of data loss or of damage to data integrity is massively reduced.

While it may seem a substantial challenge to prevent administrators from having access to data, there are at least a couple of obvious options.

Some host protection solutions claim to have separation of duties capabilities that control who can access data outside of just relying on O/S (Operating System) permissions.  I have not tested these though.

Various companies offer transparent encryption solutions that have their own set of ACLs managed independently from the O/S permissions.  These can be managed by for example the security team to ensure only approved business users can access data, while still permitting administrators to perform their role.

4. Role Based Access.

This one should hopefully require minimal explanation.  Each type of user should have a defined role.  This should have associated system permissions allowing them to access data and perform the tasks required to perform their role.

This ensures people should only be able to access data they are supposed to, and not data they should not.  The principle of ‘least privilege’ must be adhered to when creating roles and applying permissions to ensure everyone can perform their duties, but not carry out tasks outside of those that are approved.

This can be backed up by using some form of IAM (Identity and Access Management) solution.  Although be careful about over complicating this if your organisation is not large enough and complex enough to warrant a cumbersome IAM solution.

5. Segregate your networks.

In addition to external firewalls preventing access from outside your organisation, internal networks must be segregated as well.

When designing your networks, think carefully about which systems need to to talk to each other, and on which ports.

For example, do your end user systems all need to access all of the production environments?  Or do some of your teams need access to some production systems and only on specific application ports?

This point can be linked with the host protection one above as host firewalls can be used to further prevent unauthorised access to systems.  Most servers do not need to connect to all other servers in the same zone as them.  Host firewalls can be used to restrict servers from connecting to other servers they do not need to, without requiring an overly complex network design.

Strong network and system segregation will help prevent the spread of any malware or malicious users within the organisations’ IT estate, and thus help ensure data is not removed or changed.

6. If you create code, do solid code assurance.

The OWASP top 10 has changed little for several years (look it up if you are not familiar).  Applications consistently have known and well understood vulnerabilities.  These same vulnerabilities are consistently exploited by malicious people.

If you create applications ensure the code goes through rigorous manual and automated code reviews.  Ensure the application is thoroughly tested against not just the businesses functional requirements, but also the non functional requirements from the security team.

Finally, before the application or substantial change goes live ensure it is penetration / security tested by experts.

Performing all these checks does not guarantee your application cannot be hacked, but it will ensure that it is not an easy target.  Ideally these steps should be key and non negotiable parts of your organisations SDLC (Software / System Development Life Cycle).

7. Test and Audit.

Once you have the basics in place, you need to ensure they are being successfully applied.  This is where the assurance part of the security teams role comes into play.  Whether it is supporting the SDLC processes or scanning systems for outstanding patches, the security team can, and must, assure that the agreed tasks and processes are being adhered to.

This step is critical to the ongoing success of the previous items, the effort and expertise required to complete it should not be under estimated.

 

Hopefully this has supplied some clarity and context to my previous post and made my intent clear.  Let me know.

In some following posts I’ll start talking about some of the really fun and intelligent things you can start doing once the basics are in place!

K

2016 Security Resolutions

It’s that time of year again, everyone will be writing their resolutions and predictions for the year.

Will we have more of the same?  More APTs?  More nation state sponsored breaches?  DDoS?  Increased application attacks?  More mobile malware?

Probably.

We all know there will be hackers, criminals, hactivists, malicious insiders, nation state actors etc.  We also all know there will be application attacks, malware, APTs, DDoS etc.

Rather than write another predictions article I thought I’d try a slightly different tack an cover the key things I think every organisation MUST do if they are not already.

  1. Patch.  Everything.  On time.
  2. Protect your hosts.  Do application whitelisting.
  3. No admin rights for anyone who can access production data.
    1. No one with admin rights can access data.
  4. Role Based Access.
  5. Segregate your networks.
  6. If you create code, do solid code assurance.
  7. Test and Audit.

Get the basics right!  There are of course many other things to focus on, but hopefully the general idea is clear.  Organisations need to be mindful of throwing too much time and money into the latest and greatest APT protection, behavioural analysis, and overcomplicated solutions to simple problems.  Getting the basics right must be the first priority.

Remember, it is extremely likely that attackers will go after the low hanging fruit.  Even if they are  directly targeting your organisation, it is un-patched systems, people with admin rights and unprotected hosts or applications that will be attacked first.  Only after these avenues have failed will they resort to more challenging and advanced attacks.

I’ll use a follow up post to cover the above point in more detail, but wanted to get these initial thoughts up.

What do you think?  How is your organisation doing with the basics?  Do you spend too much time on new, sexy security when you don’t have the basics covered?

Happy new year all!

K

 

 

Extending the Perimeter

There are many articles covering ‘the borderless enterprise’ / de-perimeterisation and how the firewall and network perimeter are dead.  For the vast majority of enterprises I fundamentally disagree with this premise.

Most companies have and will continue to have a relatively well defined ‘core’.  This may anything from physical servers in a data centre they own through to a completely ‘virtual’ data centre in a public cloud.  What they all have in common is a set of servers / services and the associated business data that they really care about protect and have enforced rules around what and how things can connect to them.

Even in the supposedly de-perimeterised world of mobile and byod etc. the reality is that most business services will have rules around how they are connected to.  This can range from basic stateful rules that just define the network addresses, ports and protocols that are permitted but don’t do anything to interrogate the traffic that matches these basic rules, through to fully application aware Next Gen Firewalls and Web Application Firewalls that decrypt and inspect the application traffic.

I may to a further post on the subject of ‘the borderless network (or lack thereof)’ at a later date, but now I have outlined my position, that isn’t the main topic of this post.

Currently we have a situation where many companies / organisations have relatively secure, monitored and access controlled core systems that house that the bulk of their data and systems.  However how many organisations consider the security of the devices, browsers and apps that connect to them?

For me this is a clear gap in the majority of organisations security posture!

How many attacks come from compromised devices / browsers / apps connecting to organisations networks?  How much fraud occurs due to compromised end user systems that could be prevented if the compromised systems were detected?  How many attacks or fraud from malicious users could be spotted if the malicious use of the application or malicious tools being used could be alerted on? …

Considering organisations whose customers run their business through mobile or web applications how much more engaged would you be with your customers if you could alert them that their system or application / browser may be compromised?

For these examples, plus some further thoughts I’m currently investigating various ways we can monitor in real time the condition of any web browsers or mobile applications that connect to an organisations web facing systems.  These solutions involve inserting code into web pages that analyses / interrogates browsers, and code in mobile applications that analyses / interrogates the application and mobile device.  They also have various other features such as checksumming the code / application, using PKI for in app / browser encryption, and device fingerprinting.

I think solving this transparently to the end user will drive security insights, improve an organisations security posture and potentially enable closer ties to and trust from customers.

These solutions when linked to some of the current trends in authentication such as geolocation and behaviour analytics can be combined to provide security analytics of a quality far above that which is usually available.

What do you think?

Feel free to contact me via this blog if you’d like to discuss this further or share your thoughts on the security of devices connecting to your organisation.

K