Monday, March 24, 2014

Sudahkah Anda membuat Akses aman ke data center untuk partner / supplier Anda ?

Partner access: Balancing security and availability
Whenever outsiders -- partners or vendors -- are granted access to corporate systems, another wrinkle is added to the already complicated paradigm that is enterprise identity and access management. An organization needs to make sure outsiders have access to key systems and data so business runs smoothly and profitably. But, at the same time, care must be taken to ensure unwanted or hostile intruders aren't gaining malicious access into corporate systems.
In reality, secure partner access is just an extension of existing access management for mobile and remote employees -- but with a few twists. Employees are already enrolled in the organization's directory service, whether Active Directory, LDAP or some other system. They're company insiders who are already part of the network, not outsiders from another network with a different IT security set up.
So, how should an organization ensure secure access for partners and vendors, some of whom work so tightly within a company that they may almost be considered employees? Should their networks be treated as hostile connections that need to be strictly filtered, or should they be added to the standard directory service and treated like regular employees?
The answer lies somewhere between these two extremes. It depends on three factors: the type and amount of data the partner needs to access, the number of users the vendor needs to access that data and the risk level of the third party.
Before considering these factors though, it should be made clear that the decision ultimately should be driven by business requirements, not security requirements. Security requirements should be dictated by the business need, not the other way around. There is no one-size-fits-all approach to secure partner access. If the business needs it, then design the right level of security to be wrapped around it based on a thoroughrisk assessment of corporate partners.
Secure partner access approaches

There are many approaches to providing secure access to partners and vendors, from simple firewall rule exceptions to encrypted T1 lines andSSL VPN
 extranets. Here are some ways to choose the best method for securing access from partners and then best practices for implementing that solution.
The first step is to conduct a thorough risk assessment of the potential partner or vendor needing system access. This means assessing the third party the way you would assess your own company -- against your IT security policy. The obvious things to check are their security policies, access management systems, physical and personnel security, firewalls and security of IT infrastructure. This may require a visit to the partner's site to do a follow-up walkthrough.
This may seem burdensome, but remember, your security is linked to that of your partner. If there's a breach at your partner, and it involves your company's data, guess whose name gets in the headlines? The public -- and possibly lawyers -- don't distinguish between a company and its partner in such cases.
Next, review the risk assessment in light of the access required. These are the key questions: 
·         What type(s) of data does the partner need to access? 
·         Where does that data reside and on which systems? 
·         Which systems does the partner need to access and for what purpose? 
·         How often do they need access? Is it just for quarterly access to update software, for example, or daily access to update customer data feeds?
Partner access scenarios

The best way to illustrate best practices for secure partner access is through some examples. Here are five scenarios in order of ascending risk: a marketing company that needs access to analyze demographic data; a software vendor that needs to send periodic updates to update their software on a corporate system; a supplier that needs access to ship products; an offshore application development center and a contracted call center that needs full access to the customer database.
The marketing company analyzing demographic data is an example of a low-risk situation. Demographic data can't be tied to individual customers, so it can't be used for identity theft. Such data is usually used for market research or sales models. The best approach here, especially if the number of users at the vendor is small -- say, a few dozen -- is to provide limited VPN access. With SSL VPNs, like those offered by Aventail Corp., Juniper Networks Inc. and Cisco Systems Inc., the users are only allowed access to selected systems and data. In addition, access by SSL VPNs can be finely tuned by type of user and application.
A key difference between SSL VPNs and IPSec VPNs, the other type of VPN, is that an SSL VPN connects an individual user to a specific application, while an IPSec VPN connects a workstation to a network. SSL VPNs are Web-based, so they can be accessed from any browser, which means any desktop. IPSec VPNs can also be tuned to restrict users to specific applications and systems, but they offer more unrestricted access not required by users like those in our marketing company scenario.
Another popular product, similar to an SSL VPN, is Citrix Systems Inc.'s NetScaler, which also provides restricted access for remote users to specific applications through a Web browser. Both SSL VPNs and Citrix mesh well with Active Directory, allowing users from partners and vendors to be added with appropriate restrictions.
For more information:
The second scenario, a software vendor needing access to send periodic updates, can be handled a few different ways. The update can be retrieved from the vendor's Web site rather than granting the vendor system access. Other possibilities, particularly for upgrades to mainframe software, include encrypted batch feeds or the use of a secure file transfer product like Connect:Direct from Sterling Commerce. The Sterling line of products can also be used for regularly transferring other types of files securely to partners and vendors.
The third scenario, a supplier integrated into your company, hikes up the risk a notch. The supplier may need access to your inventory systems, but obviously not to customer data. This may lower the risk of identity theft, but not of physical theft. The best option may be an extranet with a secure connection, such as through an SSL VPN. IP filtering or firewall rules should also be used to prevent access of the extranet from a site other than the vendor's. Otherwise, a malicious employee at the vendor could access the site from their home and conduct unauthorized transactions, at the least.
The fourth scenario is similar to the third in that offshore developers, like suppliers, need access only to specific systems; in this case, development environments and application code. But the developers may be halfway around the world in India or China. This means that they have to connect from their own far-flung networks. The connections to your network should be through a segregated network segment on its own firewalls.
As for the fifth scenario, a third-party call center, the connection -- whether through regular TCP/IP or a T1 line -- should be both dedicated and encrypted. In this high-risk situation, where employees of a third party are dipping directly into your sensitive customer data, a multi-layered approach should be used. An SSL VPN combined with IP filtering and firewall rules limit access from the vendor. Two-factor authentication with one-time password (OTP) tokens is a thought, but the high turnover at many call centers makes this option a management nightmare. The options, of course, also depend on the type of application call center employees need to access, whether it's a mainframe green screen or Web-based, for example. Either way, VPN options, both SSL and IPSec, are available.
Finally, as with access for your own employees, all vendor and partner access needs to be logged, audited and regularly pruned to remove inactive users. From this perspective, secure partner access is no different than regular employee access. It's nothing more than creative use of VPNs, dedicated connections, IP filtering and encrypted connections.

About the author:
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP, specializing in web and application security, and the author of The Little Black Book of Computer Security available on Amazon. He hosts a regular radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at

Buat standar keamanan data center Anda

Set data center security standards to harmonize IT, business goals

IT operations teams and security teams often are at battle. Data center security standards can largely affect the people who run the systems. Tighten security too much and administrators can't do their jobs.
Application and systems programmers need authority to operate the system and to detect and fix problems. At the same time, corporations must guard against unauthorized distribution of customer, employee or other confidential information. In the interest of availability, enterprises restrict the chances of anyone making arbitrary, unscheduled or malicious changes. So, how do shops reconcile protecting data and availability while maintaining suitable access for technical support? 
Data centers have several choices in identity management, including group logon IDs, firecall IDs and alternate IDs. Let's take a look at each security measure and any associated issues.
Group logon IDs. Some shops consolidate powerful access into one logon ID that members of a functional team share. You can control access to the group ID by requiring a technician to enter an approved change number before gaining access.
This scheme has several advantages. First, every action performed by these IDs can be easily logged and audited. It also takes the power away from individuals and, depending on the controls put around the group ID, means that any changes to the system must be deliberate, scheduled and reviewed.  
Firecall IDs. Similar to group IDs, firecall IDs have a limited scope and lifetime. In general, a programmer who requires exceptional access must either check out or create a firecall ID. Additional controls may include a one-time generated password and an expiration time that limits its lifespan.
Like group IDs, firecalls can be heavily audited, and IT security can put all sorts of controls around the process for getting one. In addition, firecall access can be more granular than a group ID. For instance, while one group ID may be able to update system datasets and reorganize databases; security may set up two different firecall IDs for each distinct function.
Alternate IDs. With alternate IDs, power still rests with the individual. But instead of having full access all of the time, security teams strip the more powerful abilities from the normal ID and move them to alternate IDs. This allows technical support personnel to monitor the system with their regular ID without being able to change anything. Instead, any modifications require logging onto his or her alternate ID.
Alternate ID's provide more flexibility than firecall IDs or group IDs. They also grant faster access to update authority; however, they are harder to control.

Contending with firecall ID and group ID

Both firecall and group IDs share some problems. First, while both IDs can be heavily audited, they also make some change more anonymous. For instance, IBM's Interactive System Productivity Facility (ISPF) stores the ID of the last person to update a partition dataset (PDS) member in the library's directory. In this case, ISPF records stores the firecall or group ID, but the person using it is unknown.
Firecall IDs have an additional disadvantage with the checkout process, because sometimes a shop needs them in an emergency. If the method for getting a firecall ID takes too long or requires too much documentation or levels of approval, a short outage could easily become a long one.
Group IDs have a similar defect. Imagine having an outage in the middle of the day and the only ID powerful enough to fix it is locked up by someone who left for the day.
Here are a few best practices for maintaining secure and available data centers:
  • Allow application and systems programmers to monitor production. Despite all the recent developments in automation and "autonomic" systems, computers still need active monitoring to reach extreme availability levels. Done correctly, read access should not pose any danger to availability.
  • When comparing the three options, alternate IDs could be the best option. Alternate IDs can be logged -- just like group and firecall logons -- and they preserve some audit trails that are built into the system. Alternate IDs also allow support personnel to act quickly, when needed.
  • If a shop wants to use firecall or group IDs, they should build a process that hits the sweet spot between effective controls and speedy access. In addition, the software that controls firecall IDs should have the highest availability goals in the enterprise.
  • A department may want to designate a few dependable people with full powers in production to serve as the cavalry when things go badly. While this effectively short-circuits all the other attempts at control, it does provide for quicker problem resolution if something should happen.
Trust the technical support personnel. They dislike outages as much as management and are dedicated to the success of the enterprise.
About the author:
Robert Crawford spent 29 years as a systems programmer, covering CICS technical support, Virtual Storage Access Method, IBM DB2, IBM IMS and other mainframe products. He programmed in Assembler, Rexx, C, C++, PL/1 and COBOL. Crawford is currently an operations architect based in south Texas, establishing mainframe strategy for a large insurance