Archive for the ‘Security Postings’ Category
Wednesday, December 8th, 2010
Click jacking is headline grabbing again as Google released the latest version of its Android mobile operating system on Dec 6. Google has added security features that (they say) will harden Android to click jacking attacks.
Click jacking goes by many names including web framing attacks but they all mean the same thing: profits for the predators at the expense of their victims. The attack is correspondingly more serious with the growth in mobile friendly web sites, particularly if those web sites have not implemented anti – click jacking code. Enthusiastic smart phone users with little concept of information security are even more prone to being click jacked.
How does Click jacking Work?
Click jacking is possible because seemingly harmless features of HTML Web pages can be employed to perform unexpected actions.
A click jacked page tricks a user into performing undesired actions by clicking on a concealed link. On a click jacked page, the attackers show a set of dummy buttons, and then load another page over it in a transparent layer. The users think that they are clicking the visible buttons, while they are actually performing actions on the hidden page.
The attackers can trick users into performing actions which the users never intended to do, such as:
- performing an unintended financial transaction.
- embedding a script that can execute without the user’s knowledge.
- being redirected to a malicious web site.
Here are some examples:
• The user receives an email with a link to a video about a news item, but another valid page, say a product page on E-bay.com, can be “hidden” on top or underneath the “PLAY” button of the news video. The user tries to “play” the video but actually “buys” the product from E-bay.
• Face book was plagued with a scam that asked users to fill out a survey. The third step requested enter personal information including their phone number for a chance to win a prize. Hidden in the fine print, however, was a clause that said the user would be charged an extra $5 per week on their phone bill, as part of a so-called “Awesome Test.”
• Adobesuffered a click jack attack on their plug-in settings page. By loading this page into an invisible iframe, an attacker could trick a user into altering the security settings of Flash, giving permission for any Flash animation to utilize the computer’s microphone and camera.
FYI, Stanford University has created a strong click jack method they call tap-jacking for research purposes.
Android Touch Filtering to Reduce Click jacking
This feature is supposed to eliminate or filter out mistaken touch commands. From what I’ve read the concept is valid as it is designed to prevent the user interface from allowing security sensitive functions from being enabled while their function is being obscured by other user interface activities. This is a fancy way of preventing sloppy keying.
Since click jacking is based upon the premise of getting users to hit a key they would otherwise not click, reducing sloppy keying seems like a prudent step towards reducing click jacking.
How to Defend Against Mobile Click jacking
The two major ways of preventing click jacking are really up to the operating system vendors of smart phones and up to the operators of web sites – particularly mobile web sites.
It is up to the former to deploy defensive code in the user interface to ensure that the current frame is the most top level window, and up to the latter to send the proper browser response headers that indicate an unwillingness to be framed, called frame-breaker script.
Here’s how end users can protect themselves:
• Check the URL of a web page – be familiar with the valid name of the page you intend to visit.
• Make sure your operating system employs anti-click jacking functions.
• Ensure you’ve implemented all security patches on your software.
• Remove bogus links from any of your social networking profiles.
• Beware of any offers for free service or products.
• It’s only the predators that get something for nothing.
Have a secure week. Ron Lepofsky CISSP, CISM www.ere-security.ca
Tags: Clickjacking, mobile phone clickjacking, web framing attacks
Posted in Security Postings | No Comments »
Tuesday, November 30th, 2010
The FBI’s Internet Crime Complaint Center (IC3)recently published a warning about Smishing and Vishing. These mobile phone threats are variations of phishing, but smishing uses SMS texts to initiate the scam, while vishing uses automated phone calls.
These threats are new variations on an old and costly mythology of identity theft. The problem here is that mobile users who are novice with regard to computer security threats are simply unaware they are in jeopardy when they respond to text and audio phishing on their mobiles.
Similarly, sophisticated corporate IT users who should know better, are similarly compromised via their mobile phones.
Just to backup a step, SMS stands for short message service. SMS is also often referred to as texting, sending text messages or text messaging. The service allows for short text messages to be sent from one cell phone to another cell phone or from the Web to another cell phone. Just because the SMS service runs on a phone does not make it impervious to computer phishing.
The particularly nasty form of SMS spam called smishing, is the act of phishing by SMS for private information, often to be used for identity theft. These smishing attempts take the form of text messages and voice massages, which come to your phone saying things like “We’re confirming you’ve parcel delivery” Your account status as been changed or ABC credit card is confirming your purchase.”
The user is given a phone number to call or a website to log onto to provide account credentials to remedy the issue. Or the victim is directed to a spoofed web site. A spoofed web site is a fake site that misleads the victim into providing personal information, which is in turn routed to the scammer’s computer.
If a victim attempts to telephone back to the inbound number of a phishing call they will most probably encounter no voice mail or a constantly busy signal. This is due to attackers calling from throw-away, untraceable phones, rendering these calls virtually untraceable.
The FBI report said a recent smishing scam was used to steal money from customers of a credit union. After receiving a text about an account problem, victims called the number provided and gave out their personal information. Within 10 minutes money was withdrawn from their bank accounts. The same technique also recently used to attack banking customers who were told via text that they needed to reactivate their ATM cards at a bogus web site.
What to do. What not to do.
Once again, here are old and trusted simple steps to avoid being a victim of identity theft and fraud:
• Do not respond to respond to text messages or automated voice messages from unknown or blocked numbers.
• Do not respond to unsolicited (spam) email.
• Do not click on links contained within an unsolicited email.
• Be cautious of email claiming to contain pictures in attached files, as the files may contain viruses. Only open attachments from known senders. Avoid filling out forms contained in email messages that ask for personal information.
• Do compare the link in the email with the link to which you are directed. Look and see for yourself if it is the legitimate URL address. Better still, just log directly onto the official web site for the business identified in the email. If the email appears to be from your bank, credit card issuer, or other company you deal with frequently, your statements or official correspondence from the business will provide the proper contact information.
• Do contact the actual business that supposedly sent the email to verify if the email is genuine.
• Do verify any requests for personal information from any business or financial institution by contacting them using the main contact information.
Have a secure week. Ron Lepofsky CISSP, CISM www.ere-security.ca
Tags: Identity Theft, mobile phone identity theft, Phishing, smishing, vishing
Posted in Security Postings | 1 Comment »
Tuesday, November 9th, 2010
Last week I described real life SCADA vulnerabilities. My intent was to assist IT security people to dialogue with their executive management about security budgets. This week I will continue by identifying mitigation steps for the vulnerabilities.
I know that you already know these steps. But sometimes it’s helpful in discussions with management when you, the internal IT security team, quote recommendations by a third party, impartial security “expert”. So here goes.
CIP 002-1 Critical Cyber Asset Identification
Create a central list of critical SCADA IT assets including hardware, software, and services. The list should include both a physical and logical SCADA network diagram and an emergency contact list. This information should be regularly updated and centrally available to all people on a need to know basis. The list could be deployed in house in a format as simple as a spread sheet or on a documentation software package, or outsourced to a documentation storage provider.
CIP 003-1 Security Management Controls and CIP 007-1 Systems Security Management
Similarly to creating asset documentation above, create a set of high level policies which must be signed- off by an executive committee. No sign –off; no teeth. The document can be very short and in point-form, with a goal of creating action items to implement policy.
Then write a set of IT security procedures, starting with access and authentication controls, perhaps starting with third party access to the corporate network, then expanding to IT security operations, and then to end users. Since access and authentication controls consist of technology and people processes, both are included as part of the policy implementation budget.
In my opinion, for small and medium size organizations, policy and procedures documents should be created on spread sheets that include forms for documenting important events.
A process should be created for IT security to report their progress to the executive committee and for the executive committee to update security policy in accordance with changing business priorities. And Voila, you have created a dialogue for IT security Governance.
CIP 004-1 Personnel and Training
Ensure you include the need to enforce compliance for policy and procedures for all applicable groups. Then include compliance testing, training and IT security awareness as part of implementation.
CIP 005-1 Electronic Security Perimeter(s)
Here’s your chance to include in IT security operations procedures all the things you want to do but may not have the time or cycles (translation budget) to do: ongoing regular self initiated internal or external vulnerability assessments; structured process for implementing patches / revisions including and for: testing the updates prior to implementation, testing to ensure all intended updates were implemented successfully; implementing a robust log retention / recovery process; correlation of vulnerability assessments with current patch / revision levels; in house or third party evaluation of firewall rules to check for inconsistencies; hardening reviews of SCADA network architecture; implementation of both network and host IDS with provision for ongoing tuning out false positives; ongoing review of event logs; regular or ongoing correlation of event logs with firewall rules / IDS rules / vulnerability assessments / anti-virus or anti-spam filters.
CIP 006-1 Physical Security of Critical Cyber Assets
Again, here’s your chance to itemize budget requirements for IT physical security procedures; secured junction boxes situated in the field; implement physical security alarms on junction boxes or remote stations (attended and unattended) in the field and on doors in at the SCADA operations perimeter; visitor accompaniment or challenge policy.
CIP 008-1 Incident Reporting and Response Planning and CIP 009-1 Recovery Plans for Critical Cyber Assets
Here’s an opportunity to nudge into existence an IT security Governance process while building IT security working relationships with other departments. Request budgets for implementing; IT security incident identification, reporting and response plan; create or test outdated DRP and BCP.
We Can Not Afford All This! Or Can We?
I think you can, even with a limited budget.
The key is to write the documentation with an emphasis on ease of implementation. Keep the initial documentation short and simple, in a format that is easy to update, and keep it updated.
Once you have proved the initial policy, process, and other documentation to be successful in terms of meeting objectives, then you can look for budget to expand scope. I have seen this approach work successfully many times.
As far as technology implementation budgets, I’ve seen best success with creating a multi-year plan with smaller annual budgets. As long as you can prove success with meeting each year’s goals, your chances of getting successive budgets of course improves. Nothing succeeds like success.
Have a secure week. Ron Lepofsky CISSP, CISM www.ere-security.ca
Tags: IT security governance, IT security policy, IT security procedures, NERC CIP compliance, SCADA
Posted in Security Postings | No Comments »
Tuesday, November 2nd, 2010
Most security operations people I’ve spoken with at electrical utilities have a good handle on the security vulnerabilities within their own SCADA environments. Their problem is convincing their management to sufficiently fund remediation.
So here are just a few SCADA security related problems we’ve uncovered over the years, which may be of interest to those in control of the purse strings. I’ll mention them in order of NERC CIP compliance standards.
CIP 002-1 Critical Cyber Asset Identification
No central list of critical SCADA related software; no updated SCADA network diagram or configuration lists for SCADA servers.
CIP 003-1 Security Management Controls and CIP 007-1 Systems Security Management
Slim to none clearly written policies for: SCADA IT operations, for corporate IT operations, or for end user acceptable use. No structured regular process of communications between SCADA IT and an executive committee. I’ve never seen a good IT Security Governance process in place. No access privilege lifecycle process for network access for: previous employees, consultants, contractors, vendors, visitors.
CIP 004-1 Personnel and Training
No budget for IT security training for either SCADA operations or for end users. No security awareness program or budgeting for one. No reward system for employees who report suspicious or anomalous activity which might negatively affect security.
CIP 005-1 Electronic Security Perimeter(s)
Direct, unrestricted Internet access from network node points within junction boxes situated in the field.
No ongoing regular self initiated internal or external vulnerability assessments. No logical and physical network diagram of key elements or segments of the network. No structured process for implementing patches / revisions including; testing the updates prior to implementation, testing to ensure all intended updates were implemented successfully, insufficient logs of updates or processes for rolling back to a previous stable state. No correlation of vulnerability assessments with current patch / revision levels.
No recent evaluation of firewall rules to check for inconsistencies. SCADA network segment relying upon the corporate firewall for SCADA security. No IDS or improperly tuned IDS. No ongoing review of event logs; no correlation of event logs with firewall rules / IDS rules / vulnerability assessments / anti-virus or anti-spam filters.
CIP 006-1 Physical Security of Critical Cyber Assets
Unsecured junction boxes in the field; no physical security alarms on junction boxes or remote stations (attended and unattended) in the field; unsecured doors in at the SCADA operations perimeter. No visitor accompaniment or challenge policy.
CIP 008-1 Incident Reporting and Response Planning and CIP 009-1 Recovery Plans for Critical Cyber Assets
No incident reporting plan, documentation of any sort, or training; no definition of what an incident looks like. Untested or outdated DRP; no BCP. Ad-hoc recovery plan based upon knowledge stored in the heads of IT; difficult to have a recovery plan for critical assets when there is no list of critical assets. No updated, centrally stored list of emergency contacts for: employees, vendors, contractors, emergency services; no emergency escalation plan.
So Who’s to Blame?
In my opinion we certainly can NOT blame the IT folks. They know about the security problems. We especially cannot blame SCADA IT security groups at LDCs as NERC CIP does not mandate LDC compliance.
So the blame and responsibility must rest with the senior executives who have governance responsibility for security and who need to create the appropriate IT security budgets to allow their SCADA IT security staff to do their jobs.
Have a secure week. Ron Lepofsky CISSP, CISM www.ere-security.ca
Tags: NERC CIP, SCADA, SCADA vulnerabilities
Posted in Security Postings | No Comments »
Tuesday, October 26th, 2010
Who needs two factor authentication? Probably you.
It is not news that the privacy, confidentiality, integrity, and availability of corporate and institutional data is at risk to cyber attack. Reducing the risk of unauthorized access to the “golden eggs” of data is paramount.
I think that one of the best current ways to harden access control, particularly for remote users accessing corporate applications, is with 2 factor authentication. Two factor authentication requires the user of data to have two correct elements concurrently available to them in order to pass authentication; something they have and something they know. This is somewhat stronger authentication than merely a user name and password, since it also requires the user to have possession of a specific physical device on their person during the authentication process.
If the user losses the authentication device, which is called a token, then their user name and password are useless. If someone is able to eavesdrop on a password and username, that information will also be useless as the password changes at least as often as with every session.
Any organization who takes security seriously should seriously consider implementing two factor authentication. Three of the early concerns about this technology were:
1. Managing the authentication engine.
2. Inconvenience: The tokens were just something else to carry around.
3. Management of lost tokens.
New technology and processes have addressed these issues very well, in my opinion. For instance you don’t need a token device anymore; a smart phone works well now. A smart phone running the appropriate token application communicates with the authentication server to receive a new password on a regular basis. And services now provide the authentication server as an outsourced service.
Here are a few two factor service and technology vendors you may want to investigate:
VeriSign, http://www.verisign.com/authentication/two-factor-authentication/compare-two-factor-authentication/index.html
RSA http://www.rsa.com/node.aspx?id=1313
Pinsafe http://www.swivelsecure.com/?page=principlesofpinsafe
Delfigo A multifactor authentication using multiple factors to both authenticate and to assign many levels of authorization. http://www.delfigosecurity.com/multi-factor-authentication?gclid=CNPnuqyc76QCFcZrKgod0nFo0w
Just to avoid any confusion, the two factor authentication I’m discussing here is for applications residing on servers – not authentication to gain access to an actual smart phone. For instance, Blackberry is a popular platform as a token for two factor authentication. However, this article does not cover secure access for the actual Blackberry device, which is a technology provided by RIM.
Two factor authentication also has nothing to do with Blackberry’s own encryption service. The Blackberry encryption technology is based upon RIM’s Blackberry Enterprise Server technology: http://na.blackberry.com/eng/ataglance/security/features.jsp
Do I also need Digital Signatures?
Possibly yes.
Digital signatures are complementary with two factor authentication and are definitely not mutually exclusive. Two factor authentication hardens authentication for access to applications including web facing applications. Digital signatures are used to harden proof of identity, confidentiality, integrity, and proof of sender for electronic communications and for web site access.
Have a secure week. Ron Lepofsky CISSP, CISM, www.ere-security.ca
Tags: 2 factor authentication, access control, authentication, digital signatures, two factor authentication
Posted in Security Postings | No Comments »
Tuesday, October 19th, 2010
Last week I asked if electrical utilities’ IT security is de facto guaranteed by compliance with the NERC CIP standard.
With no disrespect whatsoever intended towards NERC or their CIP standard, I continue my well intended questioning, especially after an esteemed colleague phoned me to discuss my article. So here goes.
The scope of NERC CIP does not include local distribution companies LDCs who bring electricity (or their equivalent in the natural gas industry) “the last mile” to the client. NERC CIP does mandate compliance for electrical transmission and generation utilities . Yet LDCs along with transmission and generation utilities are all capable of causing cascading network failures.
Without overdramatizing the situation, it is possible for a single node failure in any system to potentially cause successive failures to ripple through other networks to which they are connected. This concept equally applies to various types of networks including electrical, telecommunications, and of course specifically to the Internet.
This concept is described in detail with accompanying graphic illustrations the article Model for Cascading Failures in Complex Networks .
The key point here is that even a small electrical distribution network can cause a major blackout by ripple effect.
To keep on point, the role of control software in electrical networks is crucial to their stability. The article published by MIT “The 3 R’s of Critical Energy Networks: Reliability, Robustness and Resiliency” addresses how and why both SCADA and control software play a pivotal role in network stability. With the possibility of LDCs being possible instigators of cascading network failures I therefore suggest NERC CIP should equally apply to all LDCs.
Credit Due to Evolving NERC CIP Standards
I am impressed with three new NERC CIP standards:
- CIP 001-1 — Sabotage Reporting was adopted by NERC in 2009. This standard adds pro-active elements of both identifying and reporting anomalous or suspicious events and activity, and adds real-time response to the existing standard 008-1 Incident Reporting and Response Planning. This is critically important for stopping malicious activity before it causes damage and downtime.
- CIP 010 -1 cyber system categorization is pending. IT important for those responsible for SCADA security but who may have difficulty in cost justifying security budgets to senior executive. I believe this element assists the person creating the cost justification business case increase scope of their business case accordingly.
- CIP 011-1 cyber system protection is pending. This standard is an excellent drill-down to the existing 005-1 Electronic Security Perimeter and 006-1 Physical Security of Critical Cyber Assets, again valuable as a tool for those creating cost justification cases. It provides for the inclusion the appropriate scope for proposed security budgets.
While these standards are excellent additions to NERC CIP they still do not mandate compliance for LDCs.
Have a secure week. Ron Lepofsky CISSP http://www.ere-security.ca/
Tags: LDC, NERC CIP compliance, SCADA
Posted in Information Security, Internet Security, Security Postings | 1 Comment »
Thursday, October 14th, 2010
Electrical utilities regularly undergo the NERC CIP self certification (NERC CIP is an IT security standard for real time SCADA monitoring and management technology) but that does not mean they are safe.
Why?
1. Because their self certification is a point in time snapshot and does not take into account how well the IT security policies and procedures are enforced ongoing, or even if the documents are written.
2. The NERC CIP standard does not address many security issues – it is more of a general guideline. From an executive perspective NERC CIP may seem very detailed but from the perspective of a technologist it is more of a general guideline.
We know SCADA technology is vulnerable attack simply by reading reports of Stuxnet affecting thousands of computers – they may not have been NERC CIP compliant but they certainly appeared to be in a very critical nuclear infrastructure in Iran. http://homelandsecuritynewswire.com/experts-stuxnet-game-changer
Stuxnet hasn’t taught us anything we don’t already know; it just makes all the concerned folks think about impact.
Stuxnet targets Siemens SCADA systems, by exploiting vulnerabilities in Windows and by leveraging stolen certificates. The current speculation is that at team of 5 -10 experts researched and wrote Stuxnet over a period of months. So the reader may wonder if that sort of targeted, skilled attack is defendable. I say yes.
Even before Stuxnet arrived on the scene, there have been (justifiable) concerns about whether Smart Grid technology will exploited. According to the proceeding sin the Black Hat conference in Las Vegas a few months ago in July, improperly configured Smart Grid technology could provide vulnerabilities for cyber attacks on homes and the electrical grid. http://homelandsecuritynewswire.com/smart-grid-offers-target-rich-opportunities-hackers
According to Le Xie, an assistant professor of electrical and computer engineering at Texas A&M University, speaking at the IEEE SmartGridComm2010 conference in Gaithersburg, Maryland, hackers could profit at the expense of electricity consumers by influencing electricity markets by making the grid unstable and by causing blackouts. As utilities move over to open communications standards, as part of the migration to the “smart grid,” it could get even easier to intercept communications or hack into systems remotely. http://www.technologyreview.com/energy/26472/?p1=Headlines
Oh, what are we to do?
Many IT security professionals employed by electrical utilities know and have known what to do for a long time. They do not require external consultants to point out all their security vulnerabilities. The real problem is they generally need larger budgets and the attention of their executives in order to execute.
Perhaps with the event of Stuxnet, executives will be more attentive to their employees’ requests for larger IT security budgets to address:
• How deploying Smart Metering technology may threaten to compromise the SCADA network.
• How to isolate Smart Meter traffic from the SCADA network.
• How to ensure IT security policy is adequately stringent.
• How to ensure IT security policy is enforced uniformly and continuously.
Hopefully there is a bright side to Stuxnet that executives of Grid utilities will not forget about IT security compliance until their next NERC CIP compliance audit.
Have a secure week. Regards, Ron Lepofsky CISSP
Posted in Security Postings | No Comments »
Monday, August 16th, 2010
Pen tests may seem like a security test panacea. However they have been known to go terribly wrong and become vastly expensive. Here’s what you need to know to make sure you get the results you want at the price you expect.
Pen tests come in many flavours and degrees of risk. Some pen tests are active which means a security expert is actively trying to exploit security vulnerabilities that they have identified. Some are passive which means the test is really a vulnerability assessment. In a vulnerability assessment there is no active testing whatsoever.
There are black box and white box pen tests. Black box tests assume zero prior knowledge. The auditor must first do research which may include social engineering in order to create a profile of the target network. It gets better. The black box pen test can be done on a need to know basis with the IT department kept in the dark. The pen test sponsor of the audit, such as the IT Security Governance Committee, may deem it necessary to exclude members of the IT department from being informed about the test.
White box pen tests are philosophically the exact opposite of black box pen tests. White box pen tests are based upon testing specific security elements within an enterprise network and all the work is carefully choreographed in concert with the client’s IT operations group prior to commencement of the test. In my opinion this is a much better approach for the following reasons:
- The test will focus exactly on the technology that is of business concern to the enterprise.
- Reduced risk of unintended damage and downtime caused during an active pen test.
- Adequate backups can be done prior to the pen test.
If you decide on any sort of pen testing my advice is to discuss the test methodology with respect to several standards and recommended methodologies. Here are but a few to consider:
What are you trying to identify?
If your goal is to identify security and compliance vulnerabilities then I would suggest you strongly consider the white box pen test or vulnerability assessment. There is a far better return on investment, in my opinion, of paying for an auditor to find the vulnerabilities, allow you the time to fix them, and then to retest, rather than to pay someone to attempt to breach vulnerability.
The reason for this is quite simple. The time a pen test team will spend attempting to breach vulnerability is usually in direct proportion to the amount of money the client is willing to pay for the test. So test time is limited. Not so for a potential hacker. So money is better spent eliminating rather than testing a vulnerability.
It is also critical to identify exactly what elements of an infrastructure are worth examining for vulnerabilities:
- Elements facing outward toward the Internet or inward facing towards “insiders”.
- Applications – web based or otherwise.
- Server operating systems and configurations.
- Network security hardware and software.
- Network telecommunications technology.
- Network security architecture.
- Intrusion detection and IT operations response to potential threats.
- Portable device security / authentication / identity management.
Careful consideration of your business goals should point you in the right direction when choosing your pen test options.
Have a secure week.
Regards,
Ron Lepofsky CISSP, B.A. SC. (Mech Eng)
ERE Information Security and Privacy Auditors
Tags: Information Security, IT Security, Pen Test
Posted in Security Postings | 2 Comments »
Friday, June 25th, 2010
Digital certificates were originally designed to help authenticate, provide non repudiation, and to sometimes ensure integrity and confidentiality for written communication. They, of course, became the rage for securing Internet based transactions.
Today some people take for granted that digital certificates are intrinsic to any web-based transaction and that the transactions are,therefore, safe. But are the transactions safe? By the way I stand corrected – I just did a quick pole of 10 people who regularly do e-transactions on the Internet and one of the ten even knew the existence of digital certificates.
Here is what digital certificates are and how they work. Digital certificates are electronic documents, much like an electronic version of a passport. In fact they contain very similar boiler plate information about both the owner and the issuer of the certificate. The issuer is hopefully a certificate authority, analogous to an issuing Country of a passport, which is widely recognized and in whom everybody else has complete confidence.
The digital certificate also contains a secret known, again hopefully, only to the certificate owner and to the issuer. The secret is called a private password. The certificate authority also publishes a public key or password for every certificate holder. Both the public and private keys used only together can unlock the secrets otherwise encrypted by one of the keys.
For example, if Bob wants to send a confidential email to Sally, then Bob would encrypt the email with Bob’s private key and then again with Sally’s public key. Sally would decrypt Bob’s email with Bob’s public key and with her secret private key. Bob’s public key will only decrypt emails from Bob, and Sally’s private key will only decrypt emails encrypted with her public key. So confidentiality and fairly strong authentication of sender is provided.
Another example. If Bob wanted to send an open email to many people, but needed everybody to be sure that Bob was the sender, Bob would encrypt with his private key and anybody receiving the email would decrypt and read it with Bob’s public key. Bob must have been the sender, so authentication of sender is provided to some degree.
Online vendors use digital certificates in combination with the SSL protocol for their encryption algorithm, in order to protect the validity, integrity, and confidentiality of each transaction. Any visitor to a validly secured online e-transaction site should be able to view the associated digital certificate including details of the hashing algorithm used to protect their transaction. In this case, the validation only goes in one direction; only the transaction site is identifying itself conclusively to any visitor.
Yikes! SSL Meltdowns
We’ve probably all read about a recent SSL certificate validation problem stemming from a hashing algorithm. This is not the first problem with SSL. There was a doozey in 2009. And in 2008. And so on. Each time there is a problem, someone finds a resolution, such as changing a hashing algorithm.
Whether industry uses SSL or TLS there will undoubtedly be developing security vulnerabilities and remediation for them.
The big issue is how to take reasonable precautions to protect ones-self from SSL meltdowns. Here is a simple precautionary SSL check-list.
- Do verify the URL you are visiting is what you expected and not a similar URL with slashes and asterisks where they don’t belong.
- If in doubt phone the vendor’s or site.
- Do take the time to verify the digital certificate on a web site.
- If in doubt, research the certificate authority.
- Remember that not all portions of a web site are secured with SSL. Users can stray to an unprotected area of a site.
Have a secure week.
Regards,
Ron Lepofsky CISSP, B.A. SC. (Mech Eng)
ERE Information Security and Privacy Auditors
Tags: Digital Certificates, Information Security, IT Security, SSL, TLS
Posted in Security Postings | 1 Comment »
Wednesday, June 9th, 2010
NERC’s June 2, 2010 report identifies potential paths to destruction of our North American Electrical Grid (www.ere-security.ca and http://www.nerc.com/ ). These paths include co-ordinated cyber / physical / blended attacks, pandemic illness, geomagnetic disturbances and electromagnetic pulses.
In my opinion, while NERC (North American Electric Reliability Corporation, www.nerc.org ) has managed to accurately identify real security risks it has missed the main point.
Yes our energy grid is woefully in need of upgrading to mitigate the threat of a cascading failure, an example of which many of us experienced in August 2005 ( http://en.wikipedia.org/wiki/Northeast_Blackout_of_2003 ). And yes the NERC CIP 01 – 09 security standard (http://www.ere-security.ca/NERC_CIP_Compliance_Audit.html and http://www.nerc.com/page.php?cid=2|20 ) for the real time monitoring and management of electrical grids is an important and meaningful tool for making our grid more survival robust and secure.
However, the fundamental recommendation of the report calls for better co-ordination between US power-grid providers and the government. To me, government co-ordination is an oxymoron. We can all see how well government co-ordination is working on the Gulf Oil Spill.
To rid the nation from electric grid gremlins, we don’t need cooperation, we need a bigger stick.
I think the path to grid deliverance is for the government to substitute co-ordination with costly penalties for those utilities which fail to comply with the NERC CIP standard.
Expensive penalties might get utility executives to take more seriously their security risks, and maybe start by addressing the “here and now” concerns expressed by their own SCADA IT security staff. We have worked with SCADA IT staff who were already aware of existing security risks, but since an event had not yet caused a costly or embarrassing outage, their executives were loathe to invest in mitigating these risks.
So perhaps the time is right to up the ante of the downside potential cost of a security event to include a serious financial penalty. Then executives can re-evaluate their security ROI business cases to include the new downside penalty.
In our security auditing experience with electrical utilities, we have identified lots of security threats and vulnerabilities which could be compromised into disasters by very low tech and unsophisticated means. Terrorists, solar events, and pandemics are not even remotely required in order to compromise very commonly found weaknesses. Somebody with a six foot ladder and a laptop could potentially do just as much damage.
The solution to this problem is to sufficiently fund the security programs at the electrical utilities so their own security teams can adequately and reasonably implement the NERC standard, with emphasis on sections like Electronic Security Perimeter (CIP 005) and Sabatoge Reporting (CIP 001).
While it’s very exciting and stimulating to think how our electrical grid can be brought down by behemoths of nature and by evil people with mal intent, the reality is our grid is susceptible to the most simple of gremlins.
Maybe it’s time to think again.
Have a secure week.
Ron Lepofsky, CISSP, B.A.SC. (mech eng)
President,
ERE Information Security and Privacy Auditors
Tags: Energy Grid, Information Security, Internet Security, IT Security, NERC, Power Grid, Security Risks
Posted in Security Postings | 6 Comments »
|
|
