Wednesday, 28 March 2012

A question I am often asked is what is behind the name '7 Elements'. So for this blog post, I am going to explore this in more detail and go through each of the 7 Elements in turn.

The name 7 Elements reflects the belief that there are seven core activities required within an organisation's approach to information security. Only by embedding all seven can an organisation truly deliver a holistic and resilient approach to information security, and one that will enable them to meet their businesses objectives and in the end, to survive.

The Elements

Design | Build | Manage | Embed | Adapt | Sustain | Assure

Out of the seven, the following six elements provide the foundations required for a resilient approach to security:

Design:

Within this element an organisation needs to define architecture, policies and standards to deliver a resilient approach to information security.

Build:

Next we need to deploy systems and infrastructure that meet your design and protect your organisation's information.

Manage:

Ongoing management is then required to ensure
that your systems are operated securely and new projects align with your
security design. This element can also include the management of complex security testing engagements.

Embed:

Embedding security strategy, culture and awareness into your business processes is vital to the overall organisational approach to security.

Adapt:

We do not live in a static environment, thus it is vital that we can respond to changes within the threat landscape with regular reviews and updates that inform all of the elements.

Sustain:

Incidents will happen, both malicious and unintentional, so there is a need to deliver business resiliency through Incident Management and Resiliency testing.

This then brings me to what I feel is the most important and often neglected element required:

Assure:

The 7th Element is all about gaining assurance over any aspect of your approach to security, through practical and pragmatic security testing. Many organisations will focus on aspects of the other elements and fail to gain assurance that their approach actually provides the level of protection required and as such could expose the organisation to hidden risks.

Security testing allows you to test assumptions and controls that are
designed to provide a level of security and to gain assurance that that
assumption / control actually does what was expected or more importantly doesn't do something unexpected that results in a compromise of data.

Wednesday, 21 March 2012

7 Elements is always looking for talented professionals to join our
growing company. If you have a strong technical background delivering
innovative testing and have the ability to translate technical issues
into clear business related impact then we want to hear from you.

Wednesday, 14 March 2012

For the recent Security BSides London challenge I wrote, I made use of a Redis database to store user email. I had two motivations for this, firstly I didn't want the mail in the main MySQL database as that was going to be dumpable through SQL Injection, secondly, I wanted to play with Redis. :-)

Redis doesn't have much in the way of security so I knew that anyone who managed to pop the box could theoretically connect to the local Redis instance and mess around. I'll take you through the steps I took to install and harden Redis, on a Debian Squeeze GNU/Linux box.

InstallationThe first thing to do is get a copy of Redis. This is available as source tarball from their website. In this instance, the latest version is 2.4.8.

If you want to run make test you can, must admit I don't normally worry. Now you can just run the server from here if you want to but that's not normally what you would do in production. Redis provide an install script which will put everything in /usr/local by default. This is fine by me but the whole thing will be owned by and run as root. This is completely unnecessary so we'll remedy that shortly. First though, install it with its default options.

Now we turn our attention to the init script at /etc/init.d/redis_6379. We need to make a couple of amendments to specify the correct location of our pidfile and also to start the server as the redis user.

$ sudo vi /etc/init.d/redis_6379

Find the line near the top which defines the PIDFILE variable and change it to:

PIDFILE=/var/run/redis/redis_6379.pid

Now we need to add a new variable declaration. I put it just above REDISPORT but anywhere in the top of the file will technically work.

REDISUSER="redis"

Now head down the file and find the section which looks like:

echo "Starting Redis server..."$EXEC $CONF

Change it to:

echo "Starting Redis server..."/bin/su - $REDISUSER -c "$EXEC $CONF"

That's it, we're done getting it up and running. You can test the start up by issuing:

Check that it's running as the redis user which you can see above, it is.

Restrictions

So that's great, but by connecting to the local redis server on port 6379 you'd be able to issue any command including SET and other write actions. I didn't want this obviously. Password authentication can be enabled on Redis but this is as much use as a chocolate teapot when the password is a config file everyone can read. I decided to restrict the command set to only read-only commands using the very helpful rename-command feature.

You can rename any Redis command to whatever you like but if you rename it to "", ie nothing, it disables the commands. Very handy.

There were only two commands I needed for my app, GET and LRANGE so I was free to disable everything else. Redis provide a list of commands on their website at http://redis.io/commands so with a frankly hideous curl | grep | sed | cut | awk | anything else you can think of command line I parsed out all the valid commands and generated the following output which I saved in a file /etc/redis/rename-commands.conf:

The eagle-eyed among you will notice that I've renamed the SHUTDOWN command. If you rename SHUTDOWN the init script doesn't like you much and it doesn't perform a save of the data before it exits. In my case that's actually not too much of an issue as no data is being written but it's something to bear in mind on your app. If you don't rename SHUTDOWN then obviously someone can connect and shutdown your Redis instance. In a deliberately vulnerable app you might expect this, in a normal production server, hopefully not!

Now I've got this file I need to protect it and use it. I decided the redis user should not be able to edit this file and no-one else should be able to read it:

There's probably a few more things that could be done to harden it further, I would suggest looking into the authentication too. While it does sit in the config file, the same is true of a traditional database. The difference is you have much more granular control over database objects typically. With redis it's all or nothing, like having your app log in as sa.

Followers

Blog Disclaimer

All data and information provided on this site is for informational purposes only. The opinions expressed by individual Bloggers and those providing comments are theirs alone, and do not reflect the opinions of 7 Elements Ltd. 7 Elements Ltd is not responsible for the accuracy of any of the information supplied by the Bloggers.