I am following with interest the developments of the Rowhammer class of attacks and defenses, here there is one of the latest articles. (As far as I know, these are still more research subjects than real-life attacks.)
Already at the time of the Orange Book (or more correctly the “Trusted Computer System Evaluation Criteria – TCSEC”) in the ’80s, it was clear how important the hardware is in building the chain of trust on which IT Security relies.
Rowhammer attacks follow from a hardware security weakness, even if this weakness is also a hardware strength: the increase in density and decrease in size of DRAM cells, which allows to build memory banks with lower energy consumption and higher capacity. Unfortunately this allows the near-location memory bit-flipping that can give rise to a total compromise of the IT system, that is a Rowhammer attack. It is true that there exist memory banks with Error Correction Codes (ECC) which make the Rowhammer attacks quite hard, but these memory banks are more expensive, a little slower and available only on high-end server computers. One can look at it as a hardware feature which carried within an unexpected security weakness.
As it turns out, it seems very hard to find software measures which can detect, block or prevent Rowhammer attacks. Many different software defences have been proposed, but as of today none is really able to completely stop all Rowhammer types of attacks. A hardware weakness seems to require only hardware countermeasures.
To make the situation even more intriguing, the hardware-based Intel SGX security enclaves can be mixed-in in this scenario. Intel SGX is a hardware x86 instruction-set extension which allows to securely and confidentially execute programs in an isolated environment (called a “security enclave”). Nothing can directly look into a SGX security enclave, not even the Operating System, to the point that data can be computed in it even on systems controlled by an adversary (but SGX security enclaves are not immune from side-channel attacks). Rowhammer attacks cannot be performed from outside against programs running in a SGX security enclave. Vice-versa, a SGX security enclave in some conditions can run, without been detected, a Rowhammer software to attack the hardware and programs running on it. Overall it seems that Intel SGX security enclaves can provide extremely interesting IT security features but at the same time can also be abused to defeat IT security itself.
All of this becomes more worrisome when thinking of Virtual Machines and Cloud Services.
Reading news like this one, I wonder how we could improve managing IT security or just be able to keep up with the current development of IT. I see two main trends:
- complexity: IT systems are getting more complex at a very high speed; every system should connect with every other, should provide an incredibile number of features to different users, should run on many different platforms, and so on
- abstraction: to be able to manage this complexity, the approach is to abstract the programming and managing level of IT: programming can take advantage of existent modules and just connect them appropriately at the functional level, providing also functionalities to monitor and manage the IT system themselves (for example it is now possible to deploy entire applications or virtual infrastructures just with a couple of “clicks”).
But what about security? Even if each component is “secure” (according to some definition of this word), how can be evaluated the “security” of the current and future IT systems?
There is no doubt that IT security in the last years has been a difficult subject, but I believe that in the next future we’ll need some new approaches and tools to be able to tackle the management of IT security due to the ever increasing complexity of IT systems.
I have just published here the third and last article of my short series on the EU General Data Protection Regulation 2016/679 (GDPR) for IT.
In this final article I discuss a few points about the managing of data breaches and of the IT measures required to satisfy the citizens’ rights on their personal data managed by IT systems.
I have just published here the second article of my short series on the EU General Data Protection Regulation 2016/679 (GDPR) for IT.
In this article I discuss a few points about the risk-based approach requested by the GDPR which introduces the Data Protection Impact Assessment (DPIA), and a few IT security measures which should often be useful to mitigate risks to the personal data.
I have just published here the first article of a short series in which I consider some aspects of the requirements on IT systems and services due to the EU General Data Protection Regulation 2016/679 (GDPR).
I started to write these articles in an effort, first of all for myself, to understand what actually the GDPR requires from IT, which areas of IT can be impacted by it and how IT can help companies in implementing GDPR compliance. Obviously my main interest is in understanding which IT security measures are most effective in protecting GDPR data and which is the interrelation between IT security and GDPR compliance.
It is a few years that it is known that the SHA1 Cryptographic Hash Algorithm is weak, and from 2012 NIST has suggested to substitute it with SHA256 or other secure hash algorithms. Just a few days ago it has been announced the first example of this weakness, the first computed SHA1 “collision”.
Since many years have passed from the discovery of SHA1 weaknesses and some substitutes without known weaknesses are available, one would expect that almost no software is using SHA1 nowadays.
Unfortunately reality is quite the opposite: many applications depend on SHA1 in critical ways, to the point of crashing badly if they encounter a SHA1 collision. The first to fall to this has been the WebKit browser engine source code repository due to the reliance of Apache SVN on SHA1 (see eg. here). But also Git depends on SHA1 and one of the most famous adopters of Git is the Linux kernel repository (actually Linus Torvalds created Git to manage the Linux kernel source code).
For some applications to substitute SHA1 with another Hash algorithm requires to rewrite extensively large parts of the source code. This requires time, expertise and money (probably not in this order) and does not add any new features to the application! So unless it is really necessary or no way to keep using SHA1 and avoid the “collisions” is found, nobody really considers to do the substitution. (By the way, it seems that there are easy ways of adding controls to avoid the above mentioned “collisions”, so “sticking plasters” are currently applied to applications adopting SHA1).
But if we think about this issue from a “secure software development” point of view, there should not be any problem in substituting SHA1 with another Hash algorithm. Indeed designing software in a modular way and keeping in mind that cryptographic algorithms have a limited time life expectancy, it should be planned from the beginning of the software development cycle how to proceed to substitute one cryptographic algorithm with another of the same class but “safer” (whatever that means in each case).
Obviously this is not yet the case for many applications, which means that we have still to learn quite a bit on how to design and write “secure” software.
I just published a short article that can be downloaded here , about IT Security in the advent of Agile and DevOps development processes.
I tried to give a high level overview of the new opportunities and of the new and returning risks that Agile and DevOps bring to IT security management and governance. This requires that the IT security practitioners find new continuous and adaptive ways to provide to business the security of IT systems.