Security Issues in IPV6

Following are some security issues in IPv6.

• Security practitioners need education/training on IPv6.

IPv6 will come to the networks under administrator's control – it's only a matter of time. As with any new networking technology, it's essential that admins learn the basics of IPv6, especially the addressing scheme and protocols, in order to facilitate incident handling and related activities.

• Security tools need to be upgraded.

IPv6 is not backwards compatible. The hardware and software used to route traffic across networks and perform security analyses won't work with IPv6 traffic unless they are upgraded to versions that support the protocol. This is especially important to remember when it comes to perimeter-protection devices. Routers, firewalls and intrusion-detection systems may require software and/or hardware upgrades in order to "speak" IPv6. Many manufacturers already have these upgrades available. For example, Cisco networking devices support IPv6 as of IOS release 12.0S.

• Existing equipment may require additional configuration.

The devices that do support IPv6 typically treat it as an entirely separate protocol (as they should). Therefore, the access control lists, rule bases and other configuration parameters may need to be reevaluated and translated to support an IPv6 environment. Contact the appropriate manufacturers for specific instructions.

• Tunneling protocols create new risks.

The networking and security communities have invested time and energy in ensuring that IPv6 is a security-enabled protocol. However, one of the greatest risks inherent in the migration is the use of tunneling protocols to support the transition to IPv6. These protocols allow the encapsulation of IPv6 traffic in an IPv4 data stream for routing through non-compliant devices. Therefore, it's possible that users on the network can begin running IPv6 using these tunneling protocols before admins are ready to officially support it in production. If this is a concern, block IPv6 tunneling protocols (including SIT, ISATAP, 6to4 and others) at the perimeter.

• IPv6 autoconfiguration creates addressing complexity.

Autoconfiguration, another interesting IPv6 feature, allows systems to automatically gain a network address without administrator intervention. IPv6 supports two different autoconfiguration techniques. Stateful autoconfiguration uses DHCPv6, a simple upgrade to the current DHCP protocol, and doesn't reflect much of a difference from a security perspective. On the other hand, keep an eye on stateless autoconfiguration. This technique allows systems to generate their own IP addresses and checks for address duplication. This decentralized approach may be easier from a system administration perspective, but it raises challenges for those of us charged with tracking the use (and abuse!) of network resources.

• Effective rate limiting is hard to achieve

Rate limiting is a straightforward tactic which is probably use to protect the network from automated attack tools. This works on IPv4 networks, making automated attacks less likely to succeed or harder to launch by forcing hackers to deliberately slow their automated attack tools, or to use multiple hosts from which to launch attacks on the network.

The tactic doesn't really work on IPv6 networks. That's because IPv6 networks are so vast that it's impractical to rate limit at the 128-bit address level, Vyncke pointed out. In any case, hackers may be allotted millions or even billions of IPv6 addresses, meaning that to rate limit effectively admins would need to limit addresses at the 48-bit or 64-bit level. Right now it's simply not clear what practical approach should be used to provide the same level of protection. "The industry has yet to learn how to do it," Vyncke warned.

• Reputation-based protection does not (yet) exist

Many security software vendors use the reputation of IP addresses to filter out malicious websites that are known sources of malware. While reputation systems for IPv4 addresses already exist, it's a bit of a chicken-and-egg situation when it comes to IPv6. No one has established an IPv6 reputation database, so no one is using reputation-based security with IPv6 addresses -- and therefore no one is building a reputation database. It's something the security industry will surely eventually adopt, but for now it’s a missing piece in the security puzzle.

• Logging systems may not work properly

The key feature of IPv6 is that it uses 128-bit addresses, which are stored as a 39-digit string. IPv4 addresses, on the other hand, are written in the form 192.168.211.255 and may therefore be stored in a 15-character field. If the logging systems expect 15-character IP addresses, they may crash when they encounter "monster" 39 -digit IPv6 addresses (creating possible buffer overflow error-related security problems) or they may only store only the first 15 characters, rendering the logged information useless. The only solution is to upgrade all the logging systems to support IPv6 addresses.

• IPv6 may run by default

Although admins may think that they are running an IPv4-only data center, with IPv4-only IDS, monitoring and so on, but IPv6 could be activated and running without knowledge. That's because in some circumstances (such as an attacker on the network sending router advertisements), devices on he network can start communicating with each other by default over IPv6 using link-local addresses. (For more information, see the IETF Rogue IPv6 Router Advertisement Problem Statement.) "Your IDS will see none of this traffic, so you should definitely upgrade it to IPv6 now, and make sure that its operators are trained to use IPv6," warned Vyncke.

• SIEM systems may not work properly

Another problem with IPv6 is that every host -- inside or outside the network perimeter -- can have multiple IPv6 addresses simultaneously. This is not usual in the IPv4 world, and it can cause serious problems. "For example, how do admins know by looking at the logs that different entries refer to the same host?" asked Vyncke. In order to make sense of logs it is needed to be able to correlate addresses to hosts, but Vyncke warned that thus far no SIEM system fully supports IPv6 fully. It may support it at the network level, for example, but the correlation engine may not.

• Simple log analysis using grep won't work

Yet another problem is that the same IPv6 address can be written in multiple ways, for example: 2001:0DB8:0BAD::0DAD

or

2001:DB8:BAD:0:0:0:0:DAD

or

2001:db8:bad::dad (this is the canonical RFC 5952 format)

As a result, a grep search through the log files is not going to work as before. If devices log in using different IPv6 formats, it may have to reconfigure the way they log or change the way it is search to catch all the information in the logs about a device.

References:

[1]Security on IPv6 by Dequan Yang et al - IEEE Advanced Computer Control (ICACC), 2010 2nd International Conference on (Volume:3 )
[1]Global Information Assurance Certification Paper- SANS Institute.
[2]Understanding Data Security - Trends and Predictions -By Paul Rubens October 18, 2012
http://www.esecurityplanet.com/network-security/7-ipv6-security-risks.html

Improving network reliability of Wireless Sensor Networks

When talking about network reliability, we should consider the different types of networks as well. For example, Wireless Sensor Networks (WSNs) have the potential of revolutionizing the way wireless technology has been used over the decades.Monitoring critical structures such as high speed railway bridges 

requires the monitoring network to be highly reliable. However, there is still a lack of reliability studies of WSNs since,

• No attempt to define an accurate fault model from experimental evidence.
• Fault forecasting methodologies have never been applied to WSNs. 
• The majority of research results are proved by means of simulation. 
• No attempt to make the sensor nodes intelligent enough to recall the information of interest despite of corrupted signal sensed at the destination and hence to enhance the reliability of communication

Reliability in WSN reflects a functional unit’s ability to meet performance specifications over a specified period of time and this is often expressed as a probability or mean time to failure (MTTF). Factors affectio the reliablity in WSNs are as follows.

• Hardware failure
• Inappropriate communication scheme 
• Constrained resources in sensor nodes 
• Error prone wireless communication medium

Various models and techniques are used to improve reliability in WSNs.

1) Clustering is a key technique used to extend the lifetime of a sensor network by reducing energy consumption. Sensor nodes are considered to be homogeneous since the researches in the field of WSNs have been evolved, but some nodes may be of different energy to prolong the lifetime of a WSN and its reliability.

2) Also routing algorithms have been proposed for real-time wireless sensor networks using a hybrid algorithm that can increase reliability and network lifetime criterions[1]

3) A Reliability framework also build for data transport based on the different operational phases of the WSN protocols. For this, a fault model was established to capture the possible failures along with generalized data transport and reliability semantics and also developed a reliability block model based approach that exploits the decomposition of the complex data transport problem into operations and simplifies the investigation of the overall reliability of data transport. [2]

References
[1] Sanaz Naziri, Majid Haghparast and Somayeh Hasanpoor, “Improving Lifetime and Reliability in Routing Real-Time Wireless Sensor Networks based on Hybrid Algorithm” at Australian Journal of Basic and Applied Sciences, 5(9): 1105-1109, 2011

[2] Faisal Karim Shaikh, Abdelmajid Khelil and Neeraj Suri, “On Modeling the Reliability of Data Transport in Wireless Sensor Networks”, in IEEE international conference in parallel, distribute and network based processing, pp. 395-402, 2007

Information Security Management System

An information security management system (ISMS) is a set of policies and procedures for systematically managing an organization's sensitive data. The goal of an ISMS is to minimize risk and ensure business continuity by pro-actively limiting the impact of a security breach.

ISO 27001 is a specification for creating an ISMS. It does not mandate specific actions, but includes suggestions for documentation, internal audits, continual improvement, and corrective and preventive action.

Chief objective of Information Security Management is to implement the appropriate measurements in order to eliminate or minimize the impact that various security related threats and vulnerabilities might have on an organization. In doing so, Information Security Management will enable implementing the desirable qualitative characteristics of the services offered by the organization (i.e. availability of services, preservation of data confidentiality and integrity etc.).

The expertise, which are necessary to implement these steps :

1.       Define ISMS Scope

Management defines the scope and the boundaries. Implementing an ISMS is an investment. Deciding and defining the scope must be done at the strategic level of the organization to ensure returns on investment.

2.       Define ISMS Policy

Normally this is done by an ISMS Cleints in consultation with ISMS Project team (composed of representatives from the scope). Draft ISMS Policy is then shoved up management's desks for review and approval.

3.       Define a Risk Assessment approach

If you have a consultant, the consultant may do this for you unless you do some research and litmus test on the various risk assessment methods to decide which fits your organization.

4.       Identify Risk

Asset owners or penetration tester if you have one.

5.       Analysis and evaluate risk

Asset owners.

6.       Perform risk treatment

Asset owners.

7.       select control objectives and control

Asset owners.

8.       Prepare a Statement of Applicability

ISMS Clients

9.       Approve residual risks

Management.

10.   Implement controls

Asset owners. Managers. To some extent this includes everybody in the defined scope. E.g. anyone using an anti-virus software, anyone closing the door at night, etc.

11.   Carry out training and awareness

Human resources for generic IS training and awareness. Members of the ISMS Project Team for more focused training per business unit.

12.   Manage Operations of the ISMS

ISMS Project Team and ISMS Clients

13.   Manage Resources

ISMS Clients

14.   Implement detective and reactive controls for security incidents

Depends on the security incident. In my recent project, physical incidents are managed by the Facilities Department. IT-related incidents by the IT.

15.   Monitor procedures and controls

Process owners and asset owners

16.   Review ISMS regularly

Internal ISMS auditors. External ISMS auditors. ISMS Clients. Risk owners. Asset owners. Management.

17.   Carry out improvement measures

ISMS Clients.

18.   Communicate the action that has been taken

Action owner.

 Firewall Policies for a Software Development Company

Major goal of Software Development Company is to design, develop and distribute software applications, framework or platform which belongs to interested domains such as finance, security, travel and tourism, healthcare, public services etc.  Different roles associated with software development company are as follows.

• Software Development Team (Software Architects, Engineers, Developers, QA Engineers, Business Analysts, Project Managers)
• Software Deployment and Support Team (Deployment Engineers, App Support Team)
• Enterprise Management (CEO, HR personnel)
• Marketing and Sales Team
• Customers and Clients

Depending on the nature of the business and the above stakeholders, the different segments of network design of Software Development Company can be listed as follows.

• Wired LAN for enterprise users
• Wireless LAN for mobile users
• Branch offices connect via WAN
• Server Rooms (File servers, Mail servers, App servers)
• Remote Data Centers and Server farms
• DMZ which interfaces with general public
• Home users connected via VPN
• Extranet for customers and clients

Before a firewall policy is created, some form of risk analysis should be performed to develop a list of the types of traffic needed by the organization and categorize how they must be secured—including which types of traffic can traverse a firewall under what circumstances.

Generally, firewalls should block all inbound and outbound traffic that has not been expressly permitted by the firewall policy. Which kind of traffic should be blocked can be defined by firewall policy and these policies which can be applied by software development organization can be categorized as follows.

• Policies based on IP address and Protocols

Network traffic can be blocked based on source and destinations address or protocols such as FTP, HTTP

• Policies based on applications

These policies provide application layer filtering and proxy server functionality.

• Policies based on user identity

Based on user authentication by using VPN,SSL etc.

• Policies based on network activity

Based on user activities on the network.

 References :
Karen Scarfone and Paul Hoffman,"Guidelines on Firewalls and Firewall Policy" ,In NIST Special Publication 800-41, Sept 2009
(http://csrc.nist.gov/publications/nistpubs/800-41-Rev1/sp800-41-rev1.pdf)

 Automated Threat Modelling

The threat modelling process describes here is a manual process where different personnel from software development life cycle should work together. Recently there are several research works have started on automating the threat modelling process. Security testing is also labor intensive because a real-world program usually has too many invalid inputs. Also it requires engineers to have deep software security skills to carry out some of the most important steps of this process, and training them on security is expensive. So researchers are interested in finding ways to partially or fully automate the threat modelling and security testing process.

In 2012, Guifre Ruiz et al. has proposed a new automated approach to analyze software designs to identify, risk rank and mitigate potential threats to the system. They have designed a new data structure to detect threats in software designs called Identification Tree and another new data structure to classify threat countermeasures called Mitigation Trees. The information of both of these data structures has been taken from several relevant security sources and standards. They have modeled and automated approach that relies on the these data structures to identify the potential threats to a system design, to purge the less relevant threats according to the user's policies, and computes the software specifications to mitigate those threats [1].

Microsoft also introduces a threat modelling tool called Security Development Life Cycle (SDL) Threat modeling tool. It makes threat modeling easier for all developers by providing guidance on creating and analyzing threat models [2].

While threat modeling can uncover the broad threats and vulnerabilities of an embedded system, it cannot mitigate those threats. To do so, development teams must practice defensive coding, engage in frequent code reviews, and perform penetration testing.

[1]. Guifre Ruiz et al.," Automating Threat Modeling through the Software Development Life-Cycle", Sep 2012(http://research.cs.wisc.edu/mist/papers/Guifre-sep2012.pdf)
[2]. SDL Threat Modeling Tool
http://www.microsoft.com/security/sdl/adopt/threatmodeling.aspx

C++ Libraries

What is a library?

A library is a package of code that is meant to be reused by many programs. Typically C functions/C++ classes and methods which can be shared by more than one application are broken out of the application's source code, compiled and bundled into a library.

Why use libraries?

• Libraries rarely change, they do not need to be recompiled often. It would be a waste of time to recompile the library every time you wrote a program that used them.
• Each and every object file need not be stated when linking because the developer can reference the individual library. This simplifies the multiple use and sharing of software components between applications.
• Allows application vendors a way to simply release an API to interface with an application.
• Components which are large can be created for dynamic use, thus the library remain separate from the executable reducing it's size and thus disk space used. 
• Because precompiled objects are in machine language, it prevents people from accessing or changing the source code, which is important to businesses or people who don’t want to make their source code available for intellectual property reasons.

What library contains?

Typically, a C++ library comes in two pieces:

1) A header file that defines the functionality the library is exposing (offering) to the programs using it.
2) A precompiled binary that contains the implementation of that functionality pre-compiled into machine language.

Some libraries may be split into multiple files and/or have multiple header files.

Types of Libraries

There are two library types:

1)Static Library(Archive)

In windows : .lib extension

In Linux      : .a(archive)  extension

2)Dynamic Library(Shared Library)

In windows : .dll (Dyamic Link Library) extension

In Linux      : .so(Shared Object)  extension

Static Library	Dynamic Library
Consists of routines that are compiled and linked directly into your program.	Consists of routines that are loaded into your application at run time.
All the functionality of the static library becomes part of your executable.	The library does not become part of your executable — it remains as a separate unit.
Copy of the library becomes part of every executable that uses it, this can cause a lot of wasted space.	Many programs can share one copy, which saves space.
Static libraries also can not be upgraded easy — to update the library, the entire executable needs to be replaced.	Can be upgraded to a newer version without replacing all of the executables that use it.
Always loaded and whatever version of the code you compiled with is the version of the code that will run.	Dynamic libraries are stored and versioned separately.
Static binaries will load and run faster due to the fact that there is no need for extra indirection to access symbols.	Dynamic libraries are not linked into your program, programs using dynamic libraries must explicitly load and interface with the dynamic library.

References: Static and dynamic libraries

                     Static, Shared Dynamic and Loadable Linux Libraries

Setting up the Android Development Environment.

Setting up the Android Development Environment using Eclipse IDE is as follows.

•  Download  and install the latest version of Eclipse Classic for your Operating System from http://www.eclipse.org/downloads/. If you have not installed java already, you need to install JDK in order to run the Eclipse. Download the latest SDK form http://www.oracle.com/technetwork/java/javase/downloads/index.html

• Download and install the Android SDK from http://developer.android.com/sdk/index.html .Android SDK contains the core tools such as Android emulator, builder which are needed to build and run Android apps. 
• Install Android Development Tools(ADT).  ADT is an eclipse plugin and it can be installed using standard Eclipse plugin installation mechanism. ADT connects Android SDK with Eclipse.

                      In Eclipse go to Help -> Install new software and add https://dl-ssl.google.com/android/eclipse

                 

• Configure ADT – Set the Android SDK Location in ADT by going to Window -> Preferences in Eclipse

• Install Android packages – Configure the installed package by Window ->Android SDK Manager.