[BreachExchange] Don't want your new system getting hacked? Follow these 13 steps and you might just avoid it

[Inga Goddijn]

http://www.zdnet.com/article/dont-want-your-new-system-getting-hacked-follow-these-13-steps-and-you-might-just-avoid-it/

The IT security arm of UK surveillance agency GCHQ has issued a series of
guidelines aimed at building secure online services
<https://www.cesg.gov.uk/guidance/security-design-principles-digital-services-0>
.

Government services that make use of sensitive data are regular targets of
hackers, and as CESG -- the information assurance arm of the spy agency --
notes, when such attacks are successful the fallout can be damaging,
expensive, and embarrassing for the organisations involved.

GCHQ knows a thing or two about hacking, of course -- and the UK government
is currently steering new legislation through parliament
<http://www.zdnet.com/article/web-snooping-law-moves-ahead-despite-warning-of-suspicionless-surveillance/>
which could help better define when GCHQ and other parts of law enforcement
are permitted to carry out hacking.

CESG said that in many cases, the worst-case hacking scenario can be
avoided if services are designed and operated with security as a core
consideration. It has published a set of design principles which it says
can help create services which are resilient to attack and easier to manage
and update.

There are four sets of guidelines: the first outlines seven points to
consider before starting a project, the second sets out 11 ways to making
services harder to compromise, the third names 13 methods to minimise the
impact of any successful attack, and the fourth details seven approaches
for detecting and managing attacks.

CESG said that its own investigations found that hackers used widely
available tools to exploit basic vulnerabilities and said these sorts of
'commodity' attacks can be stopped by well-designed systems. Its
recommendations around making services hard to compromise include:

*1. Validate or transform all external input before processing it:* Simple
data formats that can be validated are preferred to complex formats. It
notes that it is very difficult to check for malicious code in complex file
formats such as PDFs or spreadsheets, so this content should be transformed
into another format to 'neuter' any malicious content.

*2. Render untrusted content in a disposable environment:* Render any
untrusted and complex content you receive from an external source in an
environment designed to safely handle malware. Consider using
virtualisation, it says, to create an environment that is reset after
processing potentially malicious content.

*3. Only import trustworthy software and verify its legitimacy: *Use
software which has signatures you can verify to prove its integrity, and do
this automatically.

*4. Design for easy maintenance: *Check for patches regularly. Frequent
small updates are preferred over infrequent large updates.

*5. Use tried and tested frameworks:* Writing your own software from
scratch rather than building upon a common framework is a high-risk
strategy, it warns.

*6. Reduce your attack surface: *Only expose the minimum interfaces
necessary. When building upon common frameworks, disable any components and
libraries you don't need.

*7. Users with access to data should be identified and authenticated: *Data
should only be released after verifying the identity, authentication
status, and appropriate attributes of the user.

*8. Make it easy for administrators to manage access control: *Having a
unified view of access control for the service can help administrators
maintain granted permissions more easily.

*9. Don't build your own cryptographic protections: *You should only use
existing algorithms and protocols, preferably using those exposed by your
chosen software stack.

*10. Protect against spear-phishing and watering-hole attacks:* Systems
administrators should not view email or browse the web from their
administrative account or device.

*11. Make it easy for users to do the right thing: *Security breaches often
occur because users have developed workarounds for system inadequacies.
Make the easiest method for users to use your service the most secure.

The full set of CESG security principles can be found here
<https://www.cesg.gov.uk/guidance/security-design-principles-digital-services-0>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20160321/d4f12da1/attachment-0001.html>