Monday, October 3, 2011
We've Moved...
The Prolifics Technical Blog has moved. You can now find us at: http://expert-tech.blogspot.com/.
Thursday, March 10, 2011
Outsourcing IT
I’ve been thinking recently about the whole “Cloud” thing, “Cloud computing”, “Cloud hosting”, “Identity Management in the Cloud”, cloud-this and cloud-that. In an essence, it all seems be a business telling to its IT department – you are too expensive. We want to get rid of you, without getting rid of the services you provide.
Business knows that an IT department is important. It saves money in many ways, keeps the back-office running and helps in executing business processes. But in many organizations IT costs too much, with all its security, high availability, disaster recovery, compliance and support requirements. Business cringes seeing all the capital job proposals and budgets for IT spendings. This is why they are looking for an alternative. Say, an alternative, that gives the back-office support without having to worry about all the high-ticket items, like HA, DR and GRC. Items that IT seems to stick every year on the annual budget proposals. An this is exactly what the “cloud” tries to provide. The cloud is an abstracted business function, where all high-ticket IT items are spread over multiple clients and thus are cheaper to have for any particular client. The IT department, after all, is just a business paid expense, that has no real, intrinsic value all by itself.
The business, of course, wants the high level of service, the good “Service Level Agreement” to cover the needs of the business. This is where we enter the world of ITIL. The SLA’s the ITIL are a step in getting IT outsourced. An SLA’s without a extra value is a way to make IT separable, commoditizable. I am not saying they are bad. I am saying if you exceed at delivering the services on the SLA’s without bringing benefits to a business, you are no different than a third party outlet selling server time for a monthly fee.
So, before you dismiss the “cloud” business as yet another popular, but short lived word in the IT vernacular, think of the implications that this model has for the future of IT. There is a trend of businesses cutting back on the IT departments. I really see only one way for the IT department to survive this transition. IT can live on by becoming a cloud integration department. On the low level, someone needs to integrate in-house systems with the clouds during and after the transition to could based services. On the high level, someone needs to understand the business and to know how to map it to the services different clouds provide.
Granted, it may take a decade before the onslaught of the clouds, depending on how much push the business is doing toward cost-cutting, but start training up now for one of these roles, if you are working in an IT department.
PS. Yes, the cloud providers will need the IT skills to develop and maintain the cloud offerings, but the number of jobs will be much smaller compared to the in-house IT staff.
To see the original blog entry, please click here.
Alex Ivkin is a senior IT Security Architect with a focus in Identity and Access Management at Prolifics. Mr. Ivkin has worked with executive stakeholders in large and small organizations to help drive security initiatives. He has helped companies succeed in attaining regulatory compliance, improving business operations and securing enterprise infrastructure. Mr. Ivkin has achieved the highest levels of certification with several major Identity Management vendors and holds the CISSP designation. He is also a speaker at various conferences and an active member of several user communities.
Business knows that an IT department is important. It saves money in many ways, keeps the back-office running and helps in executing business processes. But in many organizations IT costs too much, with all its security, high availability, disaster recovery, compliance and support requirements. Business cringes seeing all the capital job proposals and budgets for IT spendings. This is why they are looking for an alternative. Say, an alternative, that gives the back-office support without having to worry about all the high-ticket items, like HA, DR and GRC. Items that IT seems to stick every year on the annual budget proposals. An this is exactly what the “cloud” tries to provide. The cloud is an abstracted business function, where all high-ticket IT items are spread over multiple clients and thus are cheaper to have for any particular client. The IT department, after all, is just a business paid expense, that has no real, intrinsic value all by itself.
The business, of course, wants the high level of service, the good “Service Level Agreement” to cover the needs of the business. This is where we enter the world of ITIL. The SLA’s the ITIL are a step in getting IT outsourced. An SLA’s without a extra value is a way to make IT separable, commoditizable. I am not saying they are bad. I am saying if you exceed at delivering the services on the SLA’s without bringing benefits to a business, you are no different than a third party outlet selling server time for a monthly fee.
So, before you dismiss the “cloud” business as yet another popular, but short lived word in the IT vernacular, think of the implications that this model has for the future of IT. There is a trend of businesses cutting back on the IT departments. I really see only one way for the IT department to survive this transition. IT can live on by becoming a cloud integration department. On the low level, someone needs to integrate in-house systems with the clouds during and after the transition to could based services. On the high level, someone needs to understand the business and to know how to map it to the services different clouds provide.
Granted, it may take a decade before the onslaught of the clouds, depending on how much push the business is doing toward cost-cutting, but start training up now for one of these roles, if you are working in an IT department.
PS. Yes, the cloud providers will need the IT skills to develop and maintain the cloud offerings, but the number of jobs will be much smaller compared to the in-house IT staff.
To see the original blog entry, please click here.
Alex Ivkin is a senior IT Security Architect with a focus in Identity and Access Management at Prolifics. Mr. Ivkin has worked with executive stakeholders in large and small organizations to help drive security initiatives. He has helped companies succeed in attaining regulatory compliance, improving business operations and securing enterprise infrastructure. Mr. Ivkin has achieved the highest levels of certification with several major Identity Management vendors and holds the CISSP designation. He is also a speaker at various conferences and an active member of several user communities.
Tuesday, March 8, 2011
Enterprise Single Sign-On Tug of War
A desktop based Single Sign-On solution is a joy to have, if you are a desktop user. Equally, it is a pain to have if you work for an IT department and have to support it. It looks like the middle line is very thin in many organizations and the way it moved often determines success of an Enterprise Single Sign-On implementation. Here is a quick list of the typical gripes and the responses one can provide to pull the rope to the ESSO favor.
To see the original blog entry, please click here.
Alex Ivkin is a senior IT Security Architect with a focus in Identity and Access Management at Prolifics. Mr. Ivkin has worked with executive stakeholders in large and small organizations to help drive security initiatives. He has helped companies succeed in attaining regulatory compliance, improving business operations and securing enterprise infrastructure. Mr. Ivkin has achieved the highest levels of certification with several major Identity Management vendors and holds the CISSP designation. He is also a speaker at various conferences and an active member of several user communities.
- Desktop support team: Man, it replaces the Microsoft Gina. We need to provision it to all of the existing desktops, test it on our gold build, communicate with all the user population affected…It’ll take more than you think to implement it.
- Business: Ok, so let’s see how well you manage your assets. If you know them, can provision them and keep them homogeneous you should not have too many problems. If not, let’s work on the asset management first.
- Infrastructure: Users want to be automatically logged in to an enterprise app that is not covered by ESSO yet. Now we’ve got to develop another profile. This is not easy. The development, testing and support will take a lot of time.
- Business: Yes, it is the on-going cost of the ESSO. Either engage the vendors, get the training and do it in-house, or outsource it.
- Infrastructure: Now we have to have staff to support another server, another database and a bunch of desktops.
- Security: Hey, but no more sticky notes under keyboards with passwords.
- Help desk: We are getting more calls about desktop apps incompatible with the ESSO.
- Business: The incompatible apps will have to be worked through with the desktop support and the vendors.
- Security: We do not want to accept the responsibility for accidentally exposing all personal logins people may store in ESSO, like passwords for web-mail, Internet banking, shopping, forums, you name it.
- Consultant: Set ESSO up with a personal, per-user key encryption. The downside though is if a user changes their passwords and then forgets their response to a challenge question, they will loose their stored passwords.
- Help desk: Everybody is forgetting their responses to the challenge questions. People are unhappy about having to lose their stored passwords.
- Consultant: Set ESSO up with a global key, and let the Security department worry about an appropriate use policy and the privacy policy.
- Security: We do not want to send people their on-boarding passwords plain-text in an e-mail or print them out.
- Consultant: Integrate your ESSO with an identity management solution and have it automatically distribute passwords to people’s wallets.
- Infrastructure: All the setup, configuration and support takes so much time!
- Business and End Users: Hey, it is nice not to have to type enterprise passwords every time. Helpdesk is getting less calls about recovery of forgotten passwords. It saves so much time!
To see the original blog entry, please click here.
Alex Ivkin is a senior IT Security Architect with a focus in Identity and Access Management at Prolifics. Mr. Ivkin has worked with executive stakeholders in large and small organizations to help drive security initiatives. He has helped companies succeed in attaining regulatory compliance, improving business operations and securing enterprise infrastructure. Mr. Ivkin has achieved the highest levels of certification with several major Identity Management vendors and holds the CISSP designation. He is also a speaker at various conferences and an active member of several user communities.
Tuesday, February 22, 2011
The Not-So-Secret, Secret MQ Script
For those of us who work with IBM products, we all know the power of the Information Center, or better known as the Info Center. At a client in lovely Tampa, Florida, myself and Infrastructure Practice Director, AJ Aronoff, were tasked with installing WebSphere MQ v7 and WebSphere MQ File Transfer Edition v7.0.2 onto a SUSE Enterprise Linux v11 system.
Now for those who have not installed WebSphere MQ on Linux and Unix systems, certain kernel parameters pertaining to semaphores and shared memory must be set above a certain minimal level. If these are not set, MQ may not operate correctly, which on a production system, only spells disaster. The WebSphere MQ Info Center has a “Quick Beginnings for Linux” section, which walks users through pre-installation tasks that need to be completed. Naturally, there is a section about setting the kernel parameters.
This section tells users to run the command “ipcs –l”, which displays the kernel parameters and their current settings, and provides an example of the minimal settings that MQ Server requires. The “ipcs –l” command will display the parameters in the format shown below:
One would think this format would allow an admin to check the parameter settings that MQ requires, make the changes, and move onto the install. The problem is that the Info Center page doesn’t provide this format. It provides the requirement like so:
Now examining these two formats for long enough, you can determine some of the possible correlations. But others, such as the kernel.sem setting, can be interpreted in many ways, as some of the values could be set for multiple parameters. Research provides more hints about the other settings, such as their short name, but no solid evidence for the kernel.sem parameter. There is, however, an IBM support page devoted purely to this little problem, but also doesn’t provide a concrete translation of the kernel.sem parameter. This page would probably be ignored by an amateur user, as the title states “Unix IPC resources” instead of ‘kernel parameters’ and ‘Linux’, but by looking back at the “Quick Beginnings” page, one notices the first sentence reads “System V IPC resources”. IBM hid our now not-so-secret script, mqconfig, on this page, as long as you don’t scroll right past it. The script reads kernel and software information about the system you are running it on, compares them to the IBM standards for MQ, and prints out if the system passes or fails each of the necessary parameters.
Once the failed settings have been changed, by copying the proper settings into the sysctl.conf file, and the script is run again, the output looks like this:
So for those of you other than AJ and myself who will be installing MQ on Linux or Unix, save yourself some time and a headache, and use this handy script. It can be found here: http://www-01.ibm.com/support/docview.wss?rs=171&context=SSFKSJ&dc=DB520&dc=DB560&uid=swg21271236&loc=en_US&cs=UTF-8&lang=en&rss=ct171websphere
Patrick Brady is a Consultant at Prolifics based out of New York City. He has 3 years of consulting experience based around the WebSphere family of products, focusing on the administration side of customer implementations. He specializes in High Availability solutions for WebSphere MQ and Message Broker.
Now for those who have not installed WebSphere MQ on Linux and Unix systems, certain kernel parameters pertaining to semaphores and shared memory must be set above a certain minimal level. If these are not set, MQ may not operate correctly, which on a production system, only spells disaster. The WebSphere MQ Info Center has a “Quick Beginnings for Linux” section, which walks users through pre-installation tasks that need to be completed. Naturally, there is a section about setting the kernel parameters.
This section tells users to run the command “ipcs –l”, which displays the kernel parameters and their current settings, and provides an example of the minimal settings that MQ Server requires. The “ipcs –l” command will display the parameters in the format shown below:
One would think this format would allow an admin to check the parameter settings that MQ requires, make the changes, and move onto the install. The problem is that the Info Center page doesn’t provide this format. It provides the requirement like so:
Now examining these two formats for long enough, you can determine some of the possible correlations. But others, such as the kernel.sem setting, can be interpreted in many ways, as some of the values could be set for multiple parameters. Research provides more hints about the other settings, such as their short name, but no solid evidence for the kernel.sem parameter. There is, however, an IBM support page devoted purely to this little problem, but also doesn’t provide a concrete translation of the kernel.sem parameter. This page would probably be ignored by an amateur user, as the title states “Unix IPC resources” instead of ‘kernel parameters’ and ‘Linux’, but by looking back at the “Quick Beginnings” page, one notices the first sentence reads “System V IPC resources”. IBM hid our now not-so-secret script, mqconfig, on this page, as long as you don’t scroll right past it. The script reads kernel and software information about the system you are running it on, compares them to the IBM standards for MQ, and prints out if the system passes or fails each of the necessary parameters.
Once the failed settings have been changed, by copying the proper settings into the sysctl.conf file, and the script is run again, the output looks like this:
So for those of you other than AJ and myself who will be installing MQ on Linux or Unix, save yourself some time and a headache, and use this handy script. It can be found here: http://www-01.ibm.com/support/docview.wss?rs=171&context=SSFKSJ&dc=DB520&dc=DB560&uid=swg21271236&loc=en_US&cs=UTF-8&lang=en&rss=ct171websphere
Patrick Brady is a Consultant at Prolifics based out of New York City. He has 3 years of consulting experience based around the WebSphere family of products, focusing on the administration side of customer implementations. He specializes in High Availability solutions for WebSphere MQ and Message Broker.
Subscribe to:
Posts (Atom)
Posts
