The Problem With Digital Transformations

Digital Transformation is one of the most ubiquitous buzz words zipping around the hipstersphere these days. Every day we hear a new approach to DT, Agile, agile, cloud transformation, containerisation, data centre grandfathering… etc.

What does Digital Transformation actually mean?

Most people bearing solutions want to sell you something more complicated than you have before – at a price. It looks great and will propel you into the next century and end all your problems, right?

However, the key problem that most businesses and government departments face today is that they consistently fail to remove complexity as they try to transform. A successful transformation plan should look to reduce complexity first rather than changing technology for the sake of it. In fact I would go as far to say that digital transformation is not about platforms or web pages or agile, it is rather about quantifying the data that needs to flow in and out of your department, Ensuring you can secure that data properly then finding simple innovative ways to let the user access that data to scratch an itch. Anyone that turns up at your door telling you that you need a new web portal/phone app or widget as the focus for transformation is going to add complexity and should be avoided.

Simplify, prioritise and standardise. These are your paths to digital transformation success…

Dave Snowden On Agile Methodology

The problem with most agile methodologies in the modern environment is ensuring they are applied in the correct context. Too many people stare so close to these practices that the means start to overshadow the ends.

Dave Snowden reminds us of the importance of cognitive neuroscience, anthropology and theory informed practice in modern software development:

And that is why The Pentagon listens to him.

Maybe you should too.

Evolving Information Security For Maximum Impact

Modern Security Methods: Lean Principles

Information security is hard. Providing good security is even harder. Agile development methodology and the practice of Lean principles has allowed industry leaders to produce and deploy software faster and more frequently than in decades before. Naturally, our diligence to protect this software, and our ways of doing so, must evolve too.

Security has always followed the innovation of technology, and rightly so — seeing that without the technology, there would be nothing to protect. It is pretty obvious from simply observing current events that protecting customer data and fortifying code against attacks is something that needs to be at the forefront of modern software development.

Unfortunately, in the security profession, there always seems to be a delay between the change in software development and the change in securing that software. Problems creep in when trying to improve development workflow, and providing visible value to both the consumer of the software as well as the development organisation.

Old-school security certainly adds value to old-school operations, but frequent, iterative software releases cannot be protected by systems and methods designed to guard the monolith.

Security needs to evolve!

Old School: Out of the Loop

So, what are the constraints that antiquated methods put on flow?

There are stereotypes that you’ll hear in the IT and DevOps world, which include but are not limited to: painful change advisory board (CAB) meetings, and comically bureaucratic hierarchies of approval for technological change.

Although these processes were initially birthed from a genuine concern for security, they have in many ways lived up to their stereotypes. They have made quick patching, frequent vulnerability analysis, and integrated security ironically difficult, and in the long run, they can negatively affect the security posture of your organisation.

These limitations not only exist in infrastructure, but also in the software development lifecycle. In old-school information security, developers may work on a piece of software for months before a release. Often, security is the last stop on the tracks. When security then finds a problem with the code, the software may have to go through an extensive rewrite. In these instances, security is uninvolved, detached and not as effective as it has the potential to be.

Lean Adds Value

Value is another Lean idea that is negated from the conventional security model. A better way to say that might be the ‘perceived value’. Successful security is hard to quantify, because its correct implementation should be the lack of impact i.e. breaches, incidents or outages.

What’s even worse is that really bad security practices seemingly have the same quantifiable results, due to a lack of insight into the threat landscape. This leaves the security engineers, application security specialists and hackers in a difficult position in which they must find a way to express the risk that has been mitigated by the systems they have put in place.

New School: Continuous Deployment as a Security Feature

Successful and innovative companies like Etsy, claim that continuous deployment is their number one security feature. This should be considered across all organisations

First, frequent iterations in both software deployments and infrastructure changes allow for more thorough security and vulnerability analysis. If the change being pushed is small enough, it allows the security analysis to be extremely focused. More possible avenues of exploitation can be examined when the light is shining on only a few changes, and it’s all happening within the existing flow of the SDLC.

Second, continuous deployment forces security into a more intimate relationship with development. When that occurs, security has the opportunity to implement code-level security insight. These metrics can then be taken, and a real threat landscape can start to be revealed. This allows the value of security to be presented in a quantifiable manner. Instead of a “dysfunctional family” dynamic, development and security can start down the road of a more symbiotic relationship.

But How Do We Get There From Here?

Lean practices lend themselves well to progressive information security, but where does one start on this path? Is there developer training that needs to take place? Do policies need to formed and instigated before change can occur?

I don’t have answers to these specifically because the solutions differ between organisations. But I can say that it helps to have resources available to developers and IT operations team members. Technology employees, for the most part, are used to learning and absorbing new concepts but spend the majority of their focus elsewhere. If a simple catalogue of resources can be made available for consumption, it can highly contribute to a cultural shift.

No organisation can be perfect, however integrating high-quality, pragmatic security resources is essential to maximise your risk mitigation. Even if there is a lack of security awareness within a company, a pool of appropriately skilled resources can can have a huge impact once you convince people that security adds value.

There is awesome potential for improving the value that security offer even if you maintain your current workflow. However improving engagement combined with a modernised workflow will transform your your entire security posture. All of this is not to say that there aren’t problems with modern methods — but Agile teams that value Lean principles at least have the framework to evolve quickly to fix those problems.

Where Should We Go From Here?

Too often I still encounter an aversion to security compliance. People pay lip-service to built-in security, but don’t want to embrace the rigour that comes with undertaking such a model. Product owners over-constrain their systems by accepting project timelines at the expense of maintaining quality throughout the software development cycle. However challenging this may be, there are some areas in which we can still gain traction.

It is the process of doing security that matters more than the solutions that are in place. Security is the ability to react and adapt in order to maintain the integrity of the data and resources that it is protecting. Security, for better or worse, is dependent upon people. Educating people in a progressive manner is key to creating this change.

Creating Bootable USB On Linux / Mac

On Mac:

# sudo su –   ## (or whatever)

# diskutil list

Identify your disk/USB device

# sudo diskutil unmountDisk /dev/disk3

or

# sudo unmount /dev/xxx

# sudo dd if=input.iso of=/dev/usb_device

where input.iso is the OS iso file and /dev/usb_device is the USB device you’re writing to.

Or create an iso using

# dd if=/dev/disk3 of=~/Downloads/SDcard_image.iso [bs=1m]   ## optionally specify block size (doesn’t really matter)

 

SHARED RESPONSIBILITY OF CLOUD SECURITY

PUBLIC CLOUD SECURITY THREATS
Although the public cloud comes with great financial and technical benefits, like any other infrastructure, it also has its share of threats. Over the years, we have seen a rise in both attack frequency and diversity of malicious software used. With increases in cloud incidents related to vulnerability scanning, web application attacks and brute force attacks, it is crucial for you to understand the types of threats potentially targeting you on the cloud so you can build a security-in-depth strategy to defend your environment from malicious attacks.

Cloud security reports for 2014 indicated that web application attacks, brute force attacks and vulnerability scans were the most pronounced attacks experienced in the Cloud Hosting Provider environments, each impacting over 40% of the cloud hosting base. Brute force attacks have surged, likely due to the increasing presence of valuable data in the cloud, with vulnerability scans typically coupled with brute force attacks in terms of attack style and process.

Real-time analysis across 2200 customers with 232,364 incidents. Source: Cloud Security Report 2014.
Real-time analysis across 2200 customers with 232,364 incidents. Source: Cloud Security Report 2014.

In the next post we’ll look further at understanding this shared security responsibility model and what you can do to secure your cloud deployments.

Update hscroot authorized_keys2 file on HMC

After an HMC upgrade, sometimes you will lose entries that allow password-less logins to your HMC.

If this happens, run the following commands:

Log on to HMC manually:

ssh hscroot@hmc1

mkauthkeys -a “string”

where “string” is the whole ssh key from the remote hosts, e.g. “ssh-rsa asdfasdfasdfasdfasdfasdfasdfasdfaasdfasd= root@nim01”

Should be done!

Find Which Process Is Holding A Port Open Without lsof in AIX

Finding the process which is holding a port open in AIX can a pain if your company hasn’t enabled lsof.

Here is a workaround found through a LOT of messing around.

1) Find the tcp control block being used by the process:

# netstat -Aan |grep port_number

2) Try to remove that socket using rmsock

# rmsock tcp_control_block_reference tcpcb

3) Run ps -ef on the process to find out which process is holding the port open

Sample output:

# netstat -Aan |grep 7001
f1000e000373cbb8 tcp4       0      0  *.7001                *.*                   LISTEN
# rmsock f1000e000373cbb8 tcpcb
The socket 0xf1000e000373c808 is being held by proccess 12255362 (java).
# ps -ef |grep 12255362

# ps -ef |grep 12255362
username 12255362 19529980   4   26 Feb      – 17:25 /opt/IBM/mft/sfg/jdk/bin/java