The increased rates of hacking, together with the sophistication of methods used, is quite alarming. The Solaris attack shows a well organised, targeted and phased execution, planned with precision.
How can the development and deployment lifecycle process be improved?
The tech industry talk about development best practises and standards, and companies go further to develop their internal process and standard.
I will be using the Microsoft analysis of the Solorigate to discuss why it is vital to have a development process in place.
The affected dll was digitally signed, which means the hackers could access the source code before deployment. Let us focus on this aspect of software vulnerability.
I have heard in the past developers say, “the documentation is the code”. Unfortunately, this is where the hacking began. The development environment seems to be the least likely place an attack will occur, so everyone lets their guards down. Solorigate tells us otherwise.
So how can we improve this part of the process? I have to say, it starts with simple documentation. In your documentation, you should have critical components such as classes, subclasses and methods all listed. The fact that someone could create a class in your library undetected shows a flaw in the release process.
During the review process, check what has changed using a source-code management tool. A new class or code that is not owned by anyone in your team should alert you to an automatic software audit. Create an algorithm that will trigger security and deployment freeze escalations.
Update Security Training
In the past, security training and warnings had always focused on gaining access by obtaining passwords and or being on-site to inject malicious code. Companies security trainings need to be updated to include potential source code hacking.
Update Development Process and standards
The development communities need to be more conscious of the code they put into production and check that they know who owns all the changes. If the person has left the company, then the code should not be changing unless someone in the team changes it. Developers should cross-check all code.
Generate a list of classes, check what has been added, and verify there are no ghost developers in your team.
The Solaris hackers injected a block of code. An excellent defensive development process and standard would have caught the injected code. Invoking a thread creation process differently from the internal invocation would have been caught as this seems to violate their internal coding standard. It sticks out like a sore thumb.
Store configurations and code separately
The hack exploited known development processes. For example, the process stops when it identifies a test environment by checking for a test in the domain name. Put environment-specific information in a configuration file and tables in your database. Do not hard code names and sensitive environment information.
Create a separate repository for configuration and code. If your source code gets into the wrong hands, the configurations will not be there.