September 2014

Viewing posts from September , 2014

Omnitech will participate at IBM BusinessConnect 2014

Omnitech will with its Norwegian company, Omnitechit Security AS, participate at IBM BusinessConnect 2014, in Oslo, Norway on October 21. This years event focuses at the new digital arena on the following categories, Cloud, Big Data & Analytics, Mobile, Social Business and Security.
Omnitechit Security AS will be represented in the Security section.

More about IBM BusinessConnect 2014 at:

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.