Aujas US

An IDG Ventures Company

PCI DSS Version 2.0 – Ready?

A quick introduction to PCI DSS
Payment Card security measures
The Payment Card Industry Data Security Standard (PCI DSS) is a set of comprehensive requirements for enhancing payment account data security. It was developed by the founding payment brands of the PCI Security Standards Council, including American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc.

The PCI DSS aims to facilitate the broad adoption of consistent data security measures on a global basis. These data security standards cover everything from the point of entry of card data into a system, to how the data is processed, through secure payment applications. The PCI Security Standards Council seeks to protect and educate industry players such as merchants, processors, financial institutions, and any other organizations that store, process, and transmit cardholder data around the world.

PCI DSS version 2.0

The release of the new PCI DSS version, numbered 2.0, seems to be a source of relief to many organizations in the credit card industry as it introduces only a few new requirements and offers greater clarification and guidance to help merchants with their compliance efforts. While there were fears that the PCI Security Standards would introduce dramatic changes between version 1.2 and 2.0, instead it does much to sharpen standards with guidance and clarification of the main themes.

With 2.0, the PCI Standards Council is trying to strike a balance between its goal as a standard for securing cardholder data with the realities of implementation by the merchant and vendor communities. The changes and guidelines are more about the administration of the PCI compliance process. Organizations already compliant with 1.2 will not find it difficult to comply with 2.0.

New approaches and standards

The new standard provides a much clearer timeline for compliance with the January 2012 deadline, giving organizations time to plan and move to version 2.0. However, unlike the previous version, PCI DSS 2.0 takes a more risk-based approach, providing Qualified Security Assessors (QSAs) in organizations with more discretion in deciding what level of security is appropriate to the circumstances.

For example, the standard in encryption key management that has always required keys be refreshed annually has now been relaxed, allowing QSAs to make an informed decision on when to refresh. The new standard also advocates the value of storing system logs, both to avert attacks and trace the cause of any breach. With updated system logs and effective software solutions, organizations would be able to detect earlier if systems are being attacked.

Among the clarifications in the PCI is the reinforced need for merchants to use a “discovery methodology” to find cardholder data in their networks as well as guidance on how security should be handled with new technology such as virtualization and cloud computing. While most organizations seem to have welcomed the renewed focus on risk, a few preferred regulations detailing what exactly should be done. The new standard moves away from Open Web Application Security Project (OWASP) to allow for others. The standard also leans support to virtual machines running on a physical server as long as each serves one primary function.

Conclusion

Though the standard has not changed any paradigms, it has rationalized and adopted a more pragmatic approach. It has moved away from rigid requirements around vulnerability management, lack of support of virtualization and OWASP to a risk-aligned vulnerability management, support of virtualization and key guidance on log management. Overall the new standard provides greater clarity on security requirements, improves flexibility for merchants, helps manage evolving risks, aligns with industry best practices and decreases redundant sub-requirements.

November 29, 2010 Posted by | Data protection, IT security | , | Leave a comment

New Trends in Phishing Attacks

Quick Introduction to Phishing

Trends in PhishingThe convenience of online commerce has been embraced by both consumers and criminals alike. Phishing involves stealing consumers’ personal identity data and financial account credentials. Social-engineering schemes use fake e-mails purporting to be from legitimate businesses to lead consumers to counterfeit websites designed to trick recipients into divulging financial data such as account and PIN numbers. Technical-subterfuge schemes plant crime-ware on PCs to steal credentials directly, often using systems to steal customers’ or organizations’ sensitive information.

Besides the obvious threats associated with phishing, other adverse effects include decreasing customer confidence in online commerce, and financial losses experienced by both businesses and consumers.

Although progress has been made in identifying threats and developing countermeasures, there has also been a simultaneous increase in attack diversity and technical sophistication in phishing and online financial fraud. Technical crime-ware resources are readily available and have been streamlined and automated, allowing for use by amateur criminals, making phishing economically viable for a larger population of less sophisticated criminals.

Latest Phishing Attacks

  • Tab Napping – Imagine you open the login page for your Intranet portal, but then you open a new tab to visit another website for a few minutes, leaving the first tab unattended. When you return to your Intranet Portal the login page looks exactly how you left it. What you haven’t realized is that a fake page has taken its place, so when you type in your authentication credentials, you have inadvertently given the fraudster easy access to your account.

 

  • Spear Phishing – This is a  rising phenomena that uses official-looking e-mails to lure people to fake websites and trick them into revealing personal information. However, unlike traditional phishing, spear phishers do not send thousands of emails randomly, but target select groups with something in common—they work at the same company, bank at the same financial institution, attend the same college, order merchandise from the same website, etc. The e-mails are ostensibly sent from organizations or individuals the potential victims would normally get e-mails from, making them even more believable.

 

  • URL Obfuscation – As users learn to detect fake emails and websites, phishers use techniques such as URL obfuscation to make phishing emails and sites appear more legitimate. This mechanism misleads the victims into believing that a link and/or web site displayed in their web browser or HTML-capable email client is that of a trusted site but are then redirected to a phishing site. For example, if the legitimate URL is http://www.login.example.com, the phishing URL may be http://www.login-example.com, thus tricking the customer into trusting the site by using an easily overlooked substitution.

 

  • Filter Evasion – This is an another e-mail phishing attack where attacker sends mail with picture images attached to malicious websites to retrieve personal details.

 

  • SMishing – Attacker uses SMS to launch phishing attack on cell phones to steal sensitive information. Scam message direct you to click on malicious banking websites or call a phone number. If you visit the link it downloads viruses into your system or if you dial the number will be asked for personal information.

 

  • Specialized Malware – Over the last couple of years, malware has been increasingly used for criminal activity against users of online banking and commerce sites. Specialized malware available today can easily be reconfigured to target information from a number of different websites. Malware also provides several mechanisms for stealing data that is then used for identity theft or stealing money from a victim’s account.

Conclusion

Though people today are more aware of phishing, countermeasures need to be designed in order to deal with the increasing technical sophistication of criminals conducting phishing scams exploiting human vulnerabilities.

Phishing awareness needs to grow to include law enforcement and employees of targeted businesses so that they are able to accurately recognize scams targeting them. It is also important to remain vigilant by developing and enforcing countermeasures, making the resources for phishing both scarce and expensive with increased policing and thereby making phishing less profitable.

The message is clear – the key to protecting oneself starts with continuous education and awareness.

The Aujas Phishing Diagnostic Assessment can help your company assess and remediate phishing risks. For more information about the Diagnostic, or other Aujas services, contact Karl Kispert, VP of Business Development at 201 633 4745 or karl.kispert@aujas.com.  

November 29, 2010 Posted by | Cyber Crime, Phishing, Social Engineering | , , | 5 Comments

Mobile Security with J2ME

J2MEWith the large number of financial applications that are available for Java-enabled devices, security is of paramount importance. Java 2 Micro-Edition Connected Limited Device Configuration (J2ME CLDC) is the platform of choice when it comes to running mobile applications on resource constrained devices (cell phones, set-top boxes, etc.). The large deployment of this platform makes it a target for security attacks. The intent of this article is to provide some insight into J2ME security and the common mistakes when developing such applications.

J2ME has fewer features than Java and has a smaller and efficient Java engine designed for small devices.  We could divide the security of J2ME into three categories:

  • Compile/Runtime Security
  • Database
  • User awareness

Compile/Runtime Security. Java compiler and runtime environment through the provision of non-customizable classloaders, pre-verified midlets, protection domain policy and limited/no access to native/reflection API ensures the safety of the mobile devices.  

One of the key improvements over the few years in MIDP is to allow only the trusted application to call the protected API. All trusted API’s would be signed. The trusted store in the mobile phone is usually populated with certificates of manufacturer’s choice and not all known CA’s root certificates are part of the store. The J2ME permission class cannot be inherited to customize the need. Also the permissions are not really atomic to allow finer control. Once permission is obtained by the application from the user the application is allowed to use the resource however necessary.  

Database Security. One of the most ignored parts of the J2ME is the RMS database. The database is a simple byte-level file that stores the contents on the local phone. The security of this file is left to the manufacturers and the application developers. Most of the time the application developers are under the belief that RMS database file is safe to use and it’s well protected. This is not the case. A simple example would be to install the application on a memory card and later on mount the memory card in a computer. You could see almost all the files including the RMS file. Application developers need to realize that nothing is as secure as or more secure than their application. Application-level encryption is a must to protect the local data in the RMS database.

User Awareness. Another factor that J2ME developers should be aware of is the knowledge level of the user base. The mobile phone user is not aware of all the computer-related functionality. The fundamental difference in the user base demands a security at higher level which is less complicated. The current basic security that is implemented in all J2ME application is the certificates.  The expectation that an average user in the market would understand a certificate and invalid application is questionable. As an average phone user, the trust of an application comes from his interaction with it. This interaction should be simple enough for the end user to understand. A better user interface design could help the end user understand the messages that he sees on the screen.  Companies should take special initiatives to spread the security measures.

Bottom line, one should understand that a mobile phone is not better than a laptop; it’s pretty much the same in the hackers’ view.  Beware and be Secure

November 29, 2010 Posted by | IT security, Mobile device security | , , , , , | Leave a comment

Information Risk Management and M+As Part 2

M+A and business data accessPart 2 Implications- Unavailability of business critical applications preventing access to business data.

Approach

Organizations undergoing merger face challenges during integration in managing costs and risks and in providing long-term business value. Failure to address risks and appropriate control around IT security may escalate costs and incur higher risks.

To ensure that organizations achieve the maximum benefit during systems integration, an effective approach is to:

  • Involve IT security, audit and compliance professionals early in the integration planning along with the business owners. Our experience is that this generally a reactive effort.
  • Create an Integration team that involves people with prior M&A experience working closely with the IT Integration, IT Security and Compliance teams.
  • Focus early on IT security, risk and control along with IT integration to save cost and time while minimizing risk.

The multidisciplinary team will be better equipped to make informed decisions and move towards realistic targets of integrating people, processes and technology and minimize risk.

Though from an SOX compliance perspective , the SEC does allow organizations acquiring a company to take advantage of a one-year waiver to assess the internal control of the acquiring company, early focus on compliance while integrating IT systems, processes and people will help the combined entity to reduce the cost of compliance and minimize risk.

For the four challenges identified above, this is our approach:

1.      To address compliance requirements and establish effective and efficient internal control and risk environment for the combined entity 

  • Identify key risk and control owners for the combined entity.
  • Engage experienced finance and audit personnel for maintaining compliance during transition
  • Perform a top-down risk assessment to identify the risk profile of the combined entity and gaps existing in the risk and control environment
  • Develop a remediation work stream to fix deficiencies
  • Determine which entity’s compliance processes are the most efficient, or what needs to be modified to form a new compliance process
  • As units, functions, geographies, and processes merge, remove redundant controls, while keeping key controls to address the risks
  • Develop risk-based test plans that direct effort and resources to the controls that are related to the highest levels of risks

 

2.      To manage access rights for employees, customers, affiliates and third parties in an integrated environment

From an access management perspective, a merger brings multiple users, applications and legacy systems to be integrated for simple, faster and secure access to data. During a merger, various applications are consolidated, restructured or rebuilt and managing appropriate access to the information resource is a challenge. Security issues related to unauthorized access to data, information leakage, and regulatory requirements for protecting privacy of personnel information, need appropriate access management:

  • Inventory all regulatory requirements for access control and normalize them to get the common regulatory requirements for data access
  • Derive access policy for employees, customers, affiliates, and third parties for the combined entity
  • Identify all the applications that need to be consolidated on Day One (e.g., ERP, email system, customer portal, payroll) and the access requirements for the data in the respective applications
  • Ensure a common account termination process is in place as rogue accounts pose serious risks to business data
  • Plan and implement the unified strategy for the combined entity for data access during transition and after Day One

 

3.      Addressing privacy requirements of the combined entity 

  • Develop an integrated privacy compliance strategy for the combined entity
  • Evaluate business processes for potential high risk privacy areas
  • Develop and implement the privacy program strategy, components, policies, standards and procedures
  • Design and establish a privacy organization to govern privacy program operations
  • Develop and deploy a set of rationalized privacy controls and privacy operational processes
  • Establish privacy training, communication and awareness processes

 

4.      To manage business continuity during transition phase while integrating different IT systems, operations and people  

  • Identify the business critical applications and data for both the entities
  • Develop change control and fallback procedures for the business critical applications
  • Create an incident response plan
  • Identify people involved in change management, incident response and emergency changes and ensure their availability as per the plan with contact details.
  • Develop a communication plan

 Conclusion

In today’s environment of public scrutiny, companies cannot afford non-compliance with privacy and regulatory requirements, nor to have an event because of inappropriate access. While some companies have included compliance in their 10K as a key risk after M&A transactions, there are ways to avoid public scrutiny and minimize risk of non-compliance.

So, how do you know that the M&A process includes all the right steps to address Compliance, Risk and IT Security?

  • Plan early
  • Execute as standard post-merger integration activities
  • Address all components of Risk, Security and Control
  • Monitor and evaluate throughout the process

November 22, 2010 Posted by | Mergers and Acquisitions | , , | Leave a comment

Identity and Access Management – This must be your project, not your partners’!

Lessons Learned

Identity and Access RiskHaving been through numerous Identity and Access Management (IAM) implementations, we see two common denominators in terms of customer expectations that rear their ugly heads rather frequently:

  1. Let’s integrate everything that we have, and
  2. Let’s do it all at once

One can understand the excitement we all go through when we contemplate having a solution that allows us link so many applications, streamline processes with workflow automation and synchronize attributes across the board. While that excitement is infectious and contagious, the sound voice of reason must be heard and listened to.

It is natural for you to want to do as much as you can with a product, and it is human to want all of it done yesterday. Hence, the onus lies on the domain experts to work closely with customers (as partners, not vendors) and plan out a deployment that gives the customers the most results as soon as possible and additional benefits over subsequent phases.

The “good” partner helps the customer prioritize their needs and requirements, and establish plans to achieve those objectives over phases. Strong project management and planning are the keys to a successful IAM program. The products from various vendors are unlike those of 5 years ago, they are now mature, stable and scale exceptionally well, unless hacked to death to fulfil a few exotic requirements.

We cannot lose sight of the top benefits of having a robust IAM program toa company:

  1. IT systems and applications are constantly compliant with a variety of regulations, there are few gaps in access recertification
  2. Processes and access governance have been streamlined – business demands, business approves, and business gets – with minimal or no IT intervention
  3. Password reset is automated and secure, and helpdesk costs are under control
  4. Peace of mind

 

So next time you want to know whose side the “partner” is on, throw a plan too ambitious at them. While most will try to give you what you demand, you will know during the course of their approach whose interests they have in mind, yours or their own.  After all, it is your project and responsibility.

November 22, 2010 Posted by | identity and access management, Identity Theft, IT security, Risk management | , , , | Leave a comment

Vulnerability Management – Have You Thought about It Lately?

Vulnerability ManagementTo some of our customers, the first thing that comes to mind when we mention vulnerability management is compliance, or vulnerability scanning. But we like to encourage our customers to take a holistic approach as well and be thinking beyond a tool-based approach. We use a people and process-based approach to vulnerability management, because vulnerabilities exist in networks, applications, physical security, people (i.e., social engineering) and in the processes.

The Aujas approach provides a framework that you may want to use in creating a sustainable and organic vulnerability management program. It includes four phases: diagnose, analyze, transform, and sustain.

Diagnose. We look at the current state of the program, and then compare it to the desired future state. This involves looking at root causes for the program not working.  One example is a lack of a vulnerability rating system that does not allow prioritization based on the risk appetite of the company. This same issue then appears under incident response because the vulnerability rating system should be incorporated into the incident response program so that standardization of language and meaning happens across business units.

Analyze. In this phase we work with the client to develop key performance indicators to measure the program maturity and successes. Then we allocate resources to fixing the root cause issues and highlight where focus needs to be to properly implement a customized vulnerability program. In this phase the metrics are defined, the KPIs and collection methods associated with those metrics created. This phase highlights the issues and gaps between the current state and future state desired by the company.

Transform. In this phase, there is actual creation, rework or deletion of business processes that are inhibiting the company’s vulnerability management. An example of this is the customer’s patch response cycle: how does it change over time? Is it slow because of configuration management, etc.? Is there too much of a division of responsibility between the corporate program and implementation of patches at the division level? Perhaps there needs to be clearer delineation of responsibilities to improve the patch response cycle.

Sustain. The objective of this phase is constant measurement of program implementation and maturity. It is a culmination of all the work done in the previous phases and ensures that a metrics program is in place to identify issues and lead the company back through the methodology of identifying, analyzing, creating, reworking, and or deleting business processes, technology or positions that do not add value to the vulnerability management program.

Aujas has outlined a no nonsense approach to helping clients build a strong vulnerability management program.  Are you positioned will for the coming year with a sound program?  Asking Santa might be nice, but in reality, the elves at Aujas are more suited to deliver this present!

November 22, 2010 Posted by | IT security, Risk management, Vulnerabiliy managment | , | Leave a comment

Ephemeral Borders: Privacy and Security of Data in the Cloud

Privacy in the Cloud is fleeting

Can there be privacy in the Cloud?

Business is expanding across national borders at an accelerating rate.  Most corporations of significant size have facilities in many countries.  Cloud applications and storage offer savings and efficiencies, such as 24/7 availability of data and applications, enhanced access and elimination of costs associated with server maintenance.  Multinational corporations considering implementation or expansion of Cloud use should, however, tread cautiously, and obtain guidance on applicable privacy and security issues.

For example, litigation or government oversight proceedings involving such companies may result in demands for data originating in, say, France, yet stored in Cloud repositories in other countries  The servers will, for the most part, be located beyond the borders of France.  Personal data, which includes emails by definition, are subject to the European Union Privacy Directives and local enabling law, which hold that the personal data of an individual may not be sent outside the European Economic Area (the E.U. member states plus Norway, Switzerland, Iceland and Liechtenstein) without the individual’s consent.  Appropriately informed consent documents, then, must be drafted.  Additionally, no data of any kind may be sent outside France, pursuant to the Blocking Statute, for use in a foreign judicial proceeding.  Other states, such as Switzerland, have similar statutes.  Criminal penalties lie for violation of these provisions.  Data sent to Cloud repositories, then, with the intent of onward transfer for litigation, may run afoul of these laws.  In addition, The Data Protection Authority of the German state of Schlewsig-Holstein recently opined that it is a violation of German law to send data to Cloud repositories for which the servers are located outside the European Union.

Those companies registered with the U.S. Safe Harbor Program would require amendment to comprise personal data in the Cloud repositories. The Service Level Agreements with the Cloud providers must contain provisions for E.U. levels of security and privacy in the Cloud repositories (other countries where the company does business will have similar provisions) or, perhaps, provisions that the data will not be transferred to or stored in locations outside the country in which the data were created.

Finally, multinationals considering the significant economic and security advantages the Cloud offers would need documented protocols for Legal Holds for data in Cloud repositories.  Legal Holds are considered “processing” of data in the E.U., and must be done in a manner consistent with the Privacy Directives and for retrieval and production of such data to governmental agencies and courts.  

Security consultants, working closely with U.S.-based counsel experienced in cross-border data disclosure conflicts, can assist in navigating the byways of this new and complicated area of information governance.  This is where Aujas can help.

This article provided by Kenneth N. Rashbaum, Esq.     Rashbaum Associates, LLC

November 15, 2010 Posted by | Cloud Security, Risk management | , | 1 Comment

Information Risk Management Concerns in Merger & Acquisition – A Point of View

Integrating Risk, Compliance and Security Components into the Post-Merger Integration Process

M+AOver last few years, the Merger and Acquisition space has witnessed high growth. However, as experience shows,  getting a deal executed is only half the job done. Capturing the actual value in M&A comes from appropriate and timely post-merger integration of people, operations, processes, information systems, and culture.

Historic data indicates that most M&A deals failed to realize value due to ineffective post-merger integration. This has forced companies to look at post M&A integration activity as a program with set milestones. Companies today create separate integration teams with a Project Management Office and clear reporting structure. While companies look at retaining customers and key employees, integrating finance and IT functions, and addressing tax and other operational issues, they often fail to identify and address the risk and control environment. This can affect a company’s security and internal control environment.  Appropriately addressing security, risk and control issues can save time and compliance cost while minimizing business and legal risk for the combined entity.

Key Security, Risk and Control Challenges

1.       How to address compliance requirements and create an effective risk and control environment

When two companies merge, their separate compliance requirements need to be integrated. With different structures, processes, geographies and separate applicability, it becomes difficult to remain compliant, especially during post-merger integration.  Further, the risk profile of the merged entity might be different from the pre-merger entities, as there are significant changes in materiality, processes, supporting technology, and control owners.

Implications- Non compliance, ineffective and inefficient internal audit functions, lack of key risk and control owners, and a higher cost of compliance are some of the common implications.

2.       How to manage access rights for employees, customers, affiliates and third parties in an integrated environment

Mergers bring new users, applications and legacy systems to be integrated for simple, faster and secure access to data.  Therefore managing appropriate access to data is critical from both risk and compliance perspectives.  Inappropriate access to confidential data can lead to information leakage and loss in competitiveness along with non –compliance penalties.

Implications- Failure to manage access rights to business critical applications and data can lead to a) Unauthorized access to critical business data; b) No access to authorized users; c) Excess privileges to some/all users; d) Fewer privileges to authorized user; e) Operational ineffectiveness due to inappropriate access management.

3.       How to address privacy requirements of the combined entity

Two companies storing Personally Identifiable Information (PII) for employees, business partners and customers are managed through separate privacy programs, processes and systems. 

Implications– Disclosure of private information to unauthorized users can lead to regulatory and legal implications.

4.       How to manage business continuity during transition phase while integrating different IT systems, operations and people

Consolidating ERP, CRM, and other business, combining complex infrastructures of two organizations and changing how people access organization data and critical business applications warrants a robust and updated business continuity plan for recovery and continuity in the event of any disaster or malfunction of IT system or access infrastructure.

Implications- Unavailability of business critical applications preventing access to business data.

Next Week – Part 2 – Approach

November 15, 2010 Posted by | identity and access management, IT security, Mergers and Acquisitions, Risk management | , , , , | Leave a comment

Physical Security Controls – Where Are We Lacking?

Physical securityIn the world of increasing security threats, we’re attacked at both the physical and logical fronts. Logical damages hit organization reputations, goodwill, and company brand and trust, whereas physical damage at macro level impacts human lives and the economy. The Mumbai attacks in 2008 (often referred to as 26/11), the London public transit attacks in 2005 (often referred to as 7/7), and of course 9/11, are the real life examples that pointed to deficits in physical security controls.

When we closely examine and measure many current physical security controls, we often identify weaknesses and realize that the controls really do not provide the reliance we are looking for. It’s become important for an organization to adopt a layered approach when building its physical security controls.

Many physical security controls are reactive in nature and often times the responding professionals may not be as skilled when following a standard operating procedure for a response.  To address this situation, if the organization implemented a layered approach to physical security controls, response to complex incidents in real-time will probably reduce the risk.

Here’s a macro view of a layered approach:

  • Level 1 – Basic controls in place
  • Level 2 – Converging physical security in a single integrated system with automated standard operating procedures
  • Level 3 – Enable systems on an IP backbone and build strong IT security controls
  • Level 4 – Building KPI framework for physical security controls

With these levels, we are building a maturity framework for physical security systems, starting with basic physical security controls followed by convergence of the same on a single integrated platform that can be accessed, monitored, SOP enforcement on a web interface from any Web enabled IP device. With this Web advancement it’s important to build an IT security layer around physical security controls.  This results in a true state where there is convergence of both physical and logical controls.

Benefits to an organization by following this approach typically include:

  • Integration of current hybrid physical security controls in a single unified framework that delivers enforcement of procedures on the ground across systems
  • Delivery of strong coordination during incident management
  • Compliance with regulatory physical security control needs
  • Delivery of audit trail from systems that helps in delivering forensic investigation in real-time
  • Monitoring and improvement of physical security control operations
  • Delivery of real-time incident analysis, operation analysis

Attacks are distributed across the enterprise both at a physical and logical level. For security to be effective, it must be organized to react quickly to resolve issues across the enterprise. There is a definite need for systems that can enable a rapid response to security breaches and prompt investigation of events.  Convergence may be the answer!

November 15, 2010 Posted by | IT security, Physical Security controls, Risk management | , , , | Leave a comment

Converged Identity and Access Management – Final

Final in the series “Converged Identity and Access Management”

ID and access managementThe IT infrastructure is the backbone of a converged solution, allowing key business data to be shared across systems. For example, a company’s physical security system typically does not have critical business data such as employee status, whereas the HR department’s IT system has such knowledge.

Converging physical security with IT security isn’t easy, but the extra effort it requires can be beneficial, especially for financial, healthcare, and defense organizations. Convergence affords organizations the opportunity to align security with overall business goals, streamline business processes such as provisioning and investigations, and centralize security operations and policies.

Developing common protocols for managing access to company assets and data enables more efficient provisioning and management. Different physical and logical security systems should leverage extendable interfaces of identity management solutions and thus stay in sync. The key benefit is that security personnel continue to use tools best suited to their jobs and HR personnel continue using HR tools. Converged security systems therefore allow users to improve Return on Investment (ROI).

Key Steps for Convergence

To bridge the organizational gap, the physical security department should work directly with the IT security team to identify:

  1. Authoritative sources of key data used to determine whether a person has permissions to use a resource or access an area.
  2. Compliance or audit needs.
  3. Any business or security concerns that are unique or are especially important to an organization.
  4. Various business processes such as on-boarding, off-boarding and the responsibilities of different systems.
  5. Policies for managing employees who doesn’t have any logical accounts, e.g., cleaning staff, caterers, etc.
  6. Privacy and security policies that clearly define what personal information is to be collected, how the information will be used, who can access the information, how the information will be protected, and how the individual will control its use and provide updates to the information over time.

Effective Convergence through Events Correlation

With converged access control, organizations can correlate disparate physical and IT security events. For example, it may not seem suspicious for an employee to use a computer. However, physical/logical correlation might ensure the employee is able to access logical resources, only after he has swiped his ID card at the entry door. Or, some of the logical resources can get locked for a user as soon as he leaves the premises by using his card at the door.

Conclusion

The convergence of Identity and Access control systems is helping enterprises better protect their intellectual property, monitor the access to restricted areas and comply with regulations. It improves the operational efficiency of existing physical security systems and resources. How organizations choose to implement this is should be aligned with their business strategy and security and compliance requirements.

November 8, 2010 Posted by | identity and access management, IT security, Risk management | , , , | Leave a comment