Indian National Encryption Policy

It is interesting to note that the Government of India's Department of Engineering and Information Technology has issued National Encryption Policy for public comment.  And today the first addendum for the same has been issued for the people to refer to.  However, when it comes to the overall policy, it has been left out pretty lopsided. When I say Lopsided, I mean from the subjectiveness & perspective dependence that has been maintained throughout the Policy.

I would not get into those micro level details where the industry's who's who is making some or other comment on the types of services that would be covered and the type of data user as well as business would need to be retained for 90 days.  That's a very low level speculative inference that would differ from person to person and from perspective to perspective. My initial view was same and I also took to twitter for that :)

What my assessment of the Policy is the lacuna that is maintained by not aligning it to the industry standards and not basing it on the prevailing trends.  For that matter, one of the key aspect that I find missing is the way the Committee should have taken cognizance of the "Heart Bleed" as well as "Poodle" vulnerabilities that led to the demise of SSL as an Encryption Standard. It should have been noted that the PCI-Council has declared that SSL is no more a supported standard for encryption and that TLS 1.2 is the deficto standard until next such notification. Indian National Encryption Policy has this void in it to align itself with the latest, thought he vision and mission state so.  The policy goes anywhere else than stay around the vision and mission.

I am surprised to actually read the reference of SSL in the Policy at the time the world is moving to TLS 1.2 and the bigwigs of industry have already moved to the other side of adopting TLS 1.2.  Moreover, TLS 1.3 is already being eyed as it is slated for release by next year. We have already seen the advent of SHA3 earlier this year and the Policy still sticks around to 3DES and RC4. It needs to be noted that RC4 already has been vulnerable to attacks and can be actually be used to get some hand on the information encrypted using the encryption standard (Read - Article on Security Week - Dated March 2015). Moving on to the 3DES, it is not at all considered strong enough to protect the data and when the Target Breach happened, it was identified that 3DES was deployed and there was a lot of scrutiny on that move as to when AES was available why 3DES was used?

So, when the industry is basing their opinion on the micro issues of what to store how to store, where to store and talking about the data security & integrity from a different angle, my real concern is the coverage of obsolete standards and technologies as part of the overall Policy and basing the policy on those obsolete standards and technologies.  I am not sure why the Trade Pundit's or the bloggers in social media have not raised this issue till now.

Certainly, in its current format the Policy itself would be obsolete in not more than 6 months and that would call for next round.  But would DeitY listen to the Gen Next or are we still going to hear from the "Experienced" folks who missed to evaluate the latest and greatest developments??

Would you hear the voice of Young India or would this also go the TRAI way???

BYOD Program & Controls Requirement - II

As I wrote the previous Post - BYOD Program & Controls Requirement I received the comment on WFH, but I am certainly not covering that in this article, as that is a separate topic of discussion. What is more interesting that broke out as a discussion point with a colleague over a cup of coffee.  The discussion actually presented a counter argument to the Jump Server configuration.  

While in the discussion, I was very much inclined to and well still am that an organization as the first step to BYOD program should define the set of machines that they would allow.  It is pretty much important for the organization to define whether they are going to allow.  The Deep Dive on the topic reveals that the selection of devices would prompt additional thought process or should I say depending on the Support Strategy for the BYOD program the organization needs to define what devices would be allowed.

The various strategies would revolve around user experience v/s technological deployments. If an organization would like to restrict user experience and go with technological deployments that would ensure Data Security and related controls, the organization would then need to restrict the BYOD to Laptops and Desktops (may be or when its WFH). In this case the controls would be around the set of controls that have already been discussed in the previous post as mentioned above.

In case the organization would select User Experience then the organization would need to ensure that they provide support to any device and enhance the Mobility aspect of the user.  This decision however needs to be based on the following decisions - 

1. What applications would be supported for BYOD and what level of modifications / application changes would need to be carried out?
2. What level of Security would be needed to extend the support to the devices?
3. What would be the application support, would it be Browser based only or Client based with a part of the program sits on the client side
4. Would VPN security be extended to these Devices that would be supported?

There are many more questions that need to be answered for a Successful BYOD program. The Organization would additionally need to check if One Device One Number sort of Program be adopted or not. If the organization would decide to implement this program for increased mobility they need to ensure the Soft Phone Support. 

The BYOD Program as it seems is not actually an easy decision to take as the organization would require to answer many other questions and Specifically that would help them ensure mitigating Risks and meeting Compliance Requirements in Operationally Effective and Efficient Manner

Principles of Information Security

Information Security has three basic principles commonly referred to as the CIA Triad of Information Security (i.e. Confidentiality, Integrity and Availability). These principles include standards, conventions and mechanisms that form the basis for defining and implementing security controls and practices.

In addition to the base principles (i.e. confidentiality, availability and integrity), there are the few additional principles which are more related to the technological and process controls that could be deployed to achieve the desired level of Information Security. Following paragraphs detail the base as well as additional principles which assist in effective management of Information Security:

Confidentiality

Providing the framework to restrict data/information access, Confidentiality refers to protection of information from disclosure to or interception by unauthorized individuals. The concept of Data / Information Privacy stems out from the Confidentiality Principle.

Simple question to be answered for Confidentiality Part is - "Is the Person Accessing Data/Information the right person to do so?"

Integrity

Providing the framework for Data / Information accuracy and completeness, Integrity refers to the Quality of Data / Information. Integrity ensures that information once recorded and approved cannot be modified in an unauthorized manner through improper channels.

The focus is more so on the accuracy and completeness a the consequences of using inaccurate information could result in inaccurate / inadequate inputs for decision making purpose.

Availability

Providing the framework to the timeliness and extent of Data /Information availability to the users, Availability refers to the continuity of services and controls for the reachability of the users to the required Data / Information.

Availability also encompasses the technical deployment i.e. - networked machines and other aspects of the technology infrastructure.

Authentication

Authentication refers to the mechanism deployed to ensure that the person trying to access the Data / Information is the right person to do so. It involves the Identification step and can be called as the Gate Keeper Stage for Data / Information Access.

Authorization

Authorization refers to the mechanism deployed to control the kind of access a user gets on the Data / Information and the systems as deployed to store, process and transmit the Data / Information.Its a usual practice to define the Authorization levels as per the roles and responsibilities of the authenticated user.

Accountability

Accountability refers to the mechanism deployed to ensure that the ownership of actions carried out by a user while dealing with Data / Information could be ascertained and that the users are made responsible for the overall Security of the Data / Information.

Auditability

Auditability refers to the system controls that would ensure that the System has a mechanism to record the user actions and assist in establishing the accountability of the user. The Auditability feature is vital during troubleshooting exercises.

Assurance

Assurance highlights the need of ensuring that the interest of the various parties involved in the are safeguarded. Assurance of Data / Information Security is required from the perspective of the various stack holds including Governmental / Law enforcement Agencies, Investors, Management, Employees etc.

Awareness

Last but not the least, Awareness is still not a much stressed principle. Awareness about the Policies/Procedures/Process/Guidelines/Organizational Operating Procedures etc, provides for the mechanism of trained and efficient users, to support the Effective Processes and Procedures.