News

Blog

Viewing posts from the Blog category

Vulnerability Assessment and Penetration Test

Let’s start by establishing a fixed point: Vulnerability Assessments (VA) are not Penetration Tests (PT). If we oversimplify we could say that Penetration Tests can be considered partial Vulnerability Assessments, but also an in-depth analysis of this assertion is inaccurate and approximate. Of course, at the end of a PT you will find that on that server, on that segment of the network, or on that small piece of code there was vulnerability, but we are far from getting an exhaustive VA. In contrast, after a VA we have a nice formatted and colorful list of all possible vulnerabilities in our infrastructure, but we do not have a definite perception of how strong and impregnable our IT fortress is.

The purpose of this post is to clarify things and explain when you need to make a Vulnerability Assessment and when to make a Penetration Test.

Vulnerability Assessment is intended to identify weaknesses (infrastructure, systems engineering and application weaknesses) in our IT department; often used through automated tools (for example Nessus Vulnerability Scanner) that are able to find known vulnerabilities with unattended methods and without any operators intervention. At the end of a Vulnerability Assessment you will have a detailed list of vulnerable systems and networks with tips on countermeasures that can be taken to eliminate or at least mitigate the risk.

It is then up to the sensitivity of the security department, to the business needs, and also to the required economic effort to decide whether or not to take such countermeasures, use other ones or accept the risk.

Once you have taken all necessary countermeasures, or when you are sufficiently confident in the robustness of your own infrastructure, it is important to commission a Penetration Test. It is also very important it get it done by external third parties.

Penetration Test is intended to succeed in penetrating the security defenses, exploit some vulnerability and try to do as much damage as possible (figuratively speaking). And this is the difference: a hacker (not to be confused with a “cracker”) will use all his knowledge, all possible exploits and will create his own in order to enter the system. After a PT it often happens that you discover unknown vulnerabilities, which will then be analyzed and shared with the whole community in order to improve the level of security of all IT sectors.

Let’s try another example: after engineers have tested all the most cutting-edge alarms and intrusion detection systems in a new and very modern bank, some professional thieves are called, asking them to enter into the vault. The aim is clear: come in and take the money in the shortest time possible. The thieves will not waste time analyzing all walls of the bank inch by inch: they will shove into the first flaw that will find, and if they manage to get access, engineers have little to justify themselves…. Sometimes you just need a little note with four numbers or a distracted employee.

A Vulnerability Assessment certainly has an important role in the field of IT security: it surely provides an awareness of how big and how wide the gap is between your insecure and secure environment, and is an excellent starting point to begin to fix things. But it has two weaknesses: the first is that it relies almost exclusively on known vulnerabilities (for which it should be made at least every six months). The second is that it does not go that deep as to ensure that those vulnerabilities actually lead to potential damage. Only through a Penetration Test performed by a highly skilled team will you have the right perception of how our Fort Knox is impregnable.

Omnitech has been among the leaders for years in the industry for everything that concerns the Supply Chain Vulnerability Assessment and Penetration Testing: Omnitech provides highly specialized personnel to help your company from risk analysis to application of countermeasures up to the final assessment through its Ethical hackers.

Policies and Procedure’s Role in the Security Process

Information security is a concept that is more prominent than ever, but it is often missing in the minds both of people and companies. Companies are very concerned about managing the security of individuals, mostly to avoid accidents at work, but only in the last period the perception of a good IT security has become synonymous with a “healthy” business.

Information technology and telecommunications have become a vigorous part of everyday life (last year more than 31,000 Petabytes of data were exchanged). Companies today must appear on the web not only representing themselves, but also providing a range of services to its customers, to its partners and also to its employees.

From the strategic point of view, it is essential that the importance of information security is clear in the business mission, in order to protect corporate data.

For years, companies have managed their IT business without having a clear concept of a well-structured policy in the security framework, nor even having defined procedures aimed at mitigating the risks of cyber-attacks. As long as profits were greater than the risks and attacks, having security procedures could seem like a waste of time (and money). But when cyber-crimes are increasing day by day, an attack is not only annoying but the company loses money and its image. The company is forced to take measures, and they are sometimes taken too late.

It is therefore necessary to have clear understanding of a company security policy. A policy is a principle that guides the decision-making process toward a goal.
It is clear that to achieve the goal of an effective and efficient business data secure exchange proper handling procedures are to be implemented.

There’s not a minimum or a maximum number of policies and procedures. The complexity and the number of procedures depend on the risk acceptance and the business.
Security policies the most important (and often the most neglected) effective actions aimed at reducing the risk of a firm and it is the foundation to repelling attacks for the company. The problem is that companies often take into account unrelated procedures, perhaps by taking examples from web searches, which are not easily reconciled and are ill suited to business models. In the case where a company formulates and adopts IT security policies, some do so to comply with a legal requirement and then follow the correct procedures for policy implementation.

What is the correct way to create the right security policies? Firstly, you should check the regulatory environment in which we move and the type of data you want to protect. Another important fact is that the references to security policies are not just found from IT professionals who have to implement them, but from the whole company (e.g. from legal and HR). The rules must be:

  • Clear
  • Simple
  • Understandable
  • Achievable

by all employees and with the means at their disposal. A long security policy document with hundreds of points described in detail will be unenforceable (and incomprehensible). Security policies must be shared and approved even among non-IT professionals (legal offices, administrative), for which a leaner policy will be more manageable. Security policies need to explain the “why” there is need to protect, and the “how” will be handled by the procedures.
It is good to ask yourself a few questions when you approach writing a security policy:
Is this policy truly valuable to the pursuit of safety results?

  • Is the policy aligned with business goals?
  • Is it a few rules or is it more about a best practice?
  • Who should use this policy? (For who is this policy for?)
  • What level of detail do we want to give it?

Always remember that security policies should be subject to periodic review but especially remember to monitor them. If for some reason you do not get the desired results, it is possible that it is not because the policies were not followed, but rather because they are impractical or incorrect. Similarly, changes in the business goals policy may become obsolete, inadequate or exaggerated. It is good not to incorporate safety procedures in the policy because the former are more prone to revision and modification (for example, changing the version of the software or the operating system for a given service ) and should have a more streamlined approval process.

Today, managing the security of your IT infrastructure with robust policies and proper procedures should be considered “core” as much as the same business goals that manages this infrastructure. Every company is an entity in itself; it would be good to look at its own security policies with the same creativity and with the same force it takes for your business.

Omnitech will sponsor CYBERSECURITY SUMMIT 2014

Rome, 05th May, 2014

Omnitech will participate as a sponsor at the 2014 Cybersecurity Summit, which will be held in Rome on May 20. The event, with high-level companies as main sponsors, will deal with new aspects of cybersecurity, such as Big Data Security Intelligence, “Internet of Things” security, Cyber Crimes, Cyber Warfare and Cyber-espionage and so on.

You could find more details at: http://www.theinnovationgroup.it/eventi/cybersecurity-summit-2014-roma/

Opening in Norway

Rome, April 2014

Omnitech IT Security, the company with a holistic IT security approach have decided to open a company in Norway.

”The Nordic region is a mature IT market where IT security is a very important piece in the overall IT offering, says Roberto Mignemi, CEO of Omnitech. During 2013 we were able to start several projects with big Norwegian companies together with our partners IBM and Computer Associates. 2014 looks even more promising, that is why we have decided to form a Norwegian company to become even more local to the Norwegian market.”

The Norwegian company will be led by Krister Fransson, who also manages the swedish Omnitech entity. Krister Fransson has led several international companies within the IT security industry over the last 20 years and will focus to establish local teams in the Nordic area.

Heartbleed

Heartbleed is a very serious security vulnerabilities discovered in the OpenSSL cryptographic library; this library is used in over 60 % of the encrypted communications over the Internet.

How the official discoverers explain:

“The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users”

The bug was introduced in the Code in 2012 release of OpenSSL 1.0.1, which adds support for RFC6520 and implements the heartbeat on TLS connections. This function is to keep the channel open and prevent that client and server should renegotiate connection in the event of temporary inactivity.
Hence the pun between heartbeat and Heartbleed .

The encryption expert Bruce Schneier has called Heartbleed “a catastrophic bug in OpenSSL ” because “It allows attackers to read up to 64KB of memory” and some security researchers said:

“Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business-critical documents and communication. ”

## Code indicted

The RFC6520 protocol requires that the client send a heartbeat packet, and the server responds the with same content that he originally received from the client (so that the client recognizes as a valid answer).

The portion of the code that handles the response of the server (which contains the bug ) is in ssl/d1_both.c , and was included in the OpenSSL 1.0.1 release with this commit https://github.com/openssl/openssl / commit/4817504d069b4c5082161b02a22116ad75f822b1 .
/ * Allocate memory for the response , size is 1 byte
* Message type , plus 2 bytes payload length , plus
* Payload , plus padding
* /
OPENSSL_malloc buffer = (1 + 2 + padding + payload ) ;
bp = buffer ;

/ * Enter the response type , length and copy payload * /
* bp + + = TLS1_HB_RESPONSE ;
S2N (payload , bp) ;
memcpy ( bp , pl, payload ) ;

In the above code the variable “payload” is the size of the package declared by the client and not recalculated by the server. If the sender instead of declaring the true size of the package put 0xffff (the maximum number expressible with two unsigned bytes), the recipient would copy the 34 bytes of the packet true and others that are 65501 bytes in memory after the packet legitimate and would send them to the the sender.

It is not possible to establish in a deterministic way what contain those 65501 bytes, but some tests have revealed that in response OpenSSL can provide a lot of sensitive data, including the private key that the server uses to encrypt communications.

The worst thing is that exploit this vulnerability does not need special skills nor any form of authentication. “The currently- available proof- of-concept scripts allow any client, anywhere in the world, to perform a session hijacking attack of a logged in user”.
The most impacting consequences of Hearthbleed is that some hacker may have intercepted and stored encription key and can use it to decrypt all traffic even after the bug has been patched.
What can you do?

If you are a user

if the site is still vulnerable : do nothing, it makes no sense to change the password if the transmission channel is vulnerable.
if your site is NO more vulnerable : change your password.

If you are Site Administrator

Apply the latest OpenSS patch to remove vulnerability
Renew you server cetificate
Force all users to change their password.

Final considerations

This bug reveals a widespread problem in today security of communications; the open source software, while it allows anyone to test the code, and then, if necessary, to fix the bugs, on the other side accepts contributions audited by small groups. How many people actually control the source code?
So it is possible that security weaknesses are introduced in the code without anyone noticing or that someone notices it, does not make it public, and exploit them to their advantage. How many have identified the bug before the official discoverers and have taken advantage without making it public in the last two years? Could the same happen if the source code wasn’t public?
Probably it would have been more difficult to identify the bug experimentally rather than reading the source code.

The problem is compounded by the fact that many commercial software have open source libraries within their products amplifying the outcome of these bugs, exploiting the work of the volunteers of open source.
References:
http://heartbleed.com/
http://siamogeek.com/
http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html
https://filippo.io/Heartbleed/
https://tools.ietf.org/html/rfc6520 (rfc ufficiale)
https://www.openssl.org/news/secadv_20140407.txt
https://www.schneier.com/blog/archives/2014/04/heartbleed.html
http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
http://attivissimo.blogspot.it/search?updated-max=2014-04-11T11:59:00%2B02:00&max-results=5