Posts Tagged ‘IT Security’
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 »
Wednesday, June 2nd, 2010
Here’s a glaring example of how recreational online gaming of any sort can lead to unintentional expense and headache.
On May 27, Angela Moscaritolo at SC Magazine wrote an article about Symantec having discovered a database server hosting the stolen credentials of 44 million accounts belonging to at least 18 gaming websites. You can see the article on the ERE RSS feed or at http://www.scmagazineus.com/44-million-stolen-gaming-credentials-discovered/article/171128/e.
Online gamers own virtual assets within their games. These assets can be bought and sold for real dollars, up to thousands of dollars. An individual who steals and uses a gamer’s identity will gain access to the gamer’s assets which they can then use, sell and vandalize.
In any instance, where a gaming siter has access to their gaming membership’s credit card and banking information, the potential for identity theft and credit theft is escalated if a gamer’s credentials are already stolen.
Online gamblers face similar risks as online gamers whose credentials are stolen, with the added grief of facing a foreign jurisdiction when attempting to claim for losses against the gaming site. This is because most gaming sites, for reasons of US law, reside outside of the jurisdiction of the USA.
The same problem is faced by members of online transaction sites, where the members’ authentication credentials are stored by the transaction site. If a member’s user name and password are stolen, the member faces exactly the same potential risks as the online gamer, and is exacerbated if the member’s credit information is also electronically stored with the site.
While credit companies are implementing multi-factor authentication in order to mitigate potential fraudulent transactions, electronically stored credit card information is still a potential security and theft vulnerability. In these critical situations, my preference is to err on the side of conservatism; if anyone has access to electronic information, than potentially anybody has electronic access to that same information.
So the question is “What should gamers and transaction site members do to protect their electronic identities?”
The answers are pedantic but effective:
- Regularly change passwords. Chances are that a stolen old password will be used by a theft and, of course, will be useless.
- Use groups of passwords, prioritized by importance, for different uses. The best advice, of course, is to use a different password for every single use, including logon to your home and work computers, online banking, transaction sites, etc. This is not practical for most folks, so a tradeoff is to have a few different passwords but never use the same password for both critical and less critical applications.
- Consider storing (new!) passwords in an encrypted file or an electronic vault. Various programs and utilities are available for assisting with this process. The immediate two benefits are that people do not store their passwords in an unencrypted state and that the stress of remembering all the passwords and their use immediately disappears.
- Store the password for your “password vault” in a secure, non-electronic format or encrypt it with your own personal encryption system. For instance – add a suffix and prefix that are meaningful only to you and which are not composed of any personal information.
- Do not log onto any system over Wi-Fi or cellular network without the logon sequence being encrypted. Otherwise the logon credentials are easy prey for “man in the middle” attacks.
- Do not share passwords with anyone. Ever.
Have a secure week.
Ron Lepofsky, CISSP, B. A. SC. (Mech Engineering)
Tags: Games Online, Gaming Websites, Identity Theft, Internet Security, IT Security
Posted in Security Postings | 5 Comments »
Wednesday, May 26th, 2010
A deluge of compliance requirements have inundated organizations, which obligate information security officers to protect; sensitive personal and corporate data from theft; critical data from theft and corruption; medical and health data from theft, surveillance, and destruction.
Fundamental to these security and privacy imperatives is the ability of an organization to restrict control of access to only those individuals with the need and permission to see and change the data in question. Access should be predicated upon the ability to conclusively and positively identify an individual or entity requesting access to data, while being able to deny access to everyone and to everything else.
In my May 4 blog, Forensic Identification Using Skin Bacteria, I discussed this idea. This may or may not come to pass in the future, but it did emphasize the on-going, if somewhat imaginative research, in user identification. A more down to earth and currently available means of verifying identity is two-factor authentication or 2FA.
2FA has been around for a long time and has undergone major improvements. Now the banking industry has adopted it for the magnetic cards we use for credit and debit transactions – a pin number – which is something we know. Smart cards provide the ability to deny or permit the use of any transaction based upon the electronic identification of a card. The card is generically known as a token or something we have that is unique to us.
2FA is critical for some organizational applications and many organizations have the technical capability and financial resources to implement two-factor or even strong authentication.
However, in my opinion, the issue of 2FA is particularly important for individuals doing remote access to their business or personal computers, the reason being that individuals may not have the technical expertise or financial resources to ensure their remote communication sessions are indeed secure.
For example, I see many laptop users at public hot-spots hammering away, presumably over WiFi . (Or why else would they be at a hot-spot?) We know those networks are not secure and, therefore, the users are subject to any number of man-in-the-middle and covert surveillance attacks.
Users may think their sessions are safe as the WiFi access service announces that once a user has paid for the service, their sessions will be encrypted. However, the log-on portion of the payment transaction is wide open!
Or even worse. Many users implement all manner of RDP remote connections to their systems. I have seen numerable instances where identification and authentication by single password is done in the open. Even though the RDP session may be implemented via an unusual port number, there is still the possibility of monitoring the port activity and gaining access to the authentication data.
This problem is exacerbated by using the same user name and password for both an RDP session and for system login.
In my opinion, the bottom line is that all users of remote communication should implement some form of two-factor authentication, especially when using any or a combination of RDP, VPN, Bluetooth, WiFi, and wireless broadband.
My guiding principle for remote communication is that if I perform an unencrypted remote login to a system, then everybody on the Internet just saw my authentication credentials.
Have a secure week.
Ron Lepofsky, CISSP, B.A.SC. (mech eng)
President,
ERE Information Security and Privacy Auditors
http://www.ere-security.ca
Tags: Identity Theft, Information Security, Internet Security, IT Security, Privacy, Security
Posted in Internet Security | 1 Comment »
Wednesday, May 19th, 2010
A recent study at Carnegie Mellon University found the 18 – 25 year old population is most susceptible to spear phishing attacks and fraud. This sounds counterintuitive as this group is assumed to be particularly computer literate. Even more on point, the test group were university students and staff members. For more information please see the article in the RSS feed at www.ere-security.ca entitled “Younger Users Reveal Risky Details”, May 4, 2010.
So what can we learn from this study?
Everybody needs to be trained about phishing by “experience”. The article discusses a tool to simulate attacks and the target web site explains how the simulated attack could have resulted in fraud and how to guard against phishing.
I believe this sort of solution could be effective if sponsored and paid for by an institution that has a vested interest in the cyber security of its user base. Corporations, educational institutions including grade schools, and government agencies could all benefit from this type of cyber education by experience, particularly if the web site kept statistics about those entrapped and determined the level of success of the service over time.
However, spear phishing can still be effective in situations involving coincidence of timing, where the victim is expecting a transaction to occur and coincidentally receives a fraudulent email about that subject. For instance, someone expecting a delivery, email receipt, confirmation of a transaction, may have an irresistable urge to open a phishing email that seems relevant to their transaction.
In these situations it is important to:
- Ensure an anti-virus and anti-malware program first screens these announcement emails.
- The user verify that any attached URL is bone fide, by first searching for the legitimate URL and then comparing with the URL in the announcement email.
- Never include any additional personal information requested by an announcement email.
- Do not open unexpected or unknown attachments in email.
Have a secure week.
Regards, Ron Lepofsky, B.A. SC. (Mech Eng), CISSPERE Information Security and Privacy Compliance Auditors. www.ere-security.ca
Tags: Carnegie Mellon University, Information Security, IT Security, Phishing
Posted in Internet Security | 1 Comment »
Wednesday, May 12th, 2010
The New York Stock Exchange meltdown last Thursday gives a whole new meaning to “security vulnerability.” Imagine that supposedly technical errors in a transaction processing system could cascade into a disaster that affected literally the entire world.
According to the article in the Washington Post by Zachary Goldfarb and Jia Lynn Yang, the Exchange officials are quoted as saying the reason for the meltdown was “…probably caused by technical problems and could take weeks or months given the millions of trades being examined.” To see the article in full please visit www.ere-security.ca RSS feed May 10, 2010 or http://www.washingtonpost.com/wp-dyn/content/article/2010/05/07/AR2010050705087.html?sid=ST2010050705108
In my opinion, no matter what the New York Stock Exchange officials deem to be the perceived causes of the meltdown, two basic security practices need to be implemented in order to mitigate the chance of a repeat performance.
The first suggestion is really just plain common sense. Since it appears the Exchange is susceptible to anomalous transactions, where the requested sell price of an instrument is unreasonably below the current sell price, security policy needs to be implemented and enforced to have such transaction requests investigated by human beings prior to execution.
This type of inspection falls well within the realm of standard security practices for complex transaction processing systems, or for that matter, even the simplest web based on-line purchasing systems. In both the realms of the simple and the complex, it is customary to check data being input for “sanity” or for being credible.
The second suggestion is that anyone who is capable of entering requests for transactions into the Exchange transaction processing system, such as stock broker representatives, should undergo a regular background security appraisal for susceptibility to being induced to enter sell orders which are not deemed as credible.
Again this is Security 101, and organizations who deal with sensitive or critical data understand the need to do background checks on employees, both during the hiring process and periodically thereafter. Organizations with expertise in Information Security, such as ISACA, www.isaca.org, incorporate background checking into their cornerstone security policy document, COBIT. More information about COBIT may be found at www.isaca.org/cobit .
The Washington Post article goes on to explain the possible causation of last Thursday’s problem that caused the Exchange to temporarily drop by nearly1000 points in less than one hour, as “Computer programs designed to make lightning-fast decisions, based on complex mathematical rules, or algorithms, about what to buy and sell made massive trades without human input.” and “… electronic trading hubs had inconsistent rules about when to stop a sudden plunge in stock prices.”
While the debate continues about whether or not stock exchanges should slow down or interfere with automated trading, the root cause of the problem will still continue to exist: invalid sell requests. Automated trading may cause the observed cascade effect, but is not a root cause of the problem.
Indeed it would be productive for the Exchange to also address the second problem of resolving rule inconsistencies relating to automated trading. Again, ensuring software rules are consistent and compatible is a basic IT Security, whether designing rules for transaction processing systems or for firewalls.
While rule consistency is a laudable goal, it still will not address the root cause of the unnecessary plunge problem.
This plunge problem makes me think of an inverse “Terminator” situation. In the Terminator technology, “had malicious intent towards humanity”. I can imagine the NYSE transaction technology thinking…… “These guys want me to do what?”
Have a secure week.
Ron Lepofsky, CISSP, B.A. SC. (mechanical engineering)
www.ere-security.ca
Tags: COBIT, Information Security, ISACA, IT Security, New York Stock Exchange, NYSE, Security 101, Washington Post
Posted in Information Security | 2 Comments »
Tuesday, May 4th, 2010
Intriguing, no? The Gordon Washington University School of Medicine has observed that bacteria left on keyboards and computer mice is highly unique to its depositors, and can be collected and identified up to two weeks after it is left on the device. If you would like to see more about this article please visit: www.ere-security.ca , RSS feed, March 29, 2010.
This certainly provides another identification tool with regard to tagging unauthorized access and use of equipment and to tying an individual to an act of accessing electronics.
I’m not sure if it is legal to request a finger swab and if this new type of evidence could even be presented in court, but hey, DNA evidence had to begin its legal career at some point.
It is not that far removed from contact biometrics such as fingerprint readers and palm readers. And these are not far removed from contact with “something you have” such as an identification swipe card. Since we are already on the slippery slope of allowing contact with one’s personal identification device or hand parts, perhaps identification by personal bacteria is not that unreasonable.
Identifying who may have used a mouse or keyboard does not help a forensic investigation relating to remote unauthorized accesses. Users still make the same old mistakes with regard to preservation of forensic evidence when they become suspicious about a potential cyber attack.
Not to demean bacteria in any way, but users should and can implement the following procedures when they would like assistance in verifying that an intrusion has been committed on their system:
- Immediately telephone the IT security department and clearly identify their observations of concern, what they were doing on their workstation at the time, and the exact time / date.
- Do not continue to interact with their workstation and with any other applications / systems with which their workstation is interacting.
- Do not turn off their workstation.
- Do not attempt to run any diagnostics on their workstation.
- Do not send emails from their workstation.
The investigating forensics team should:
- Isolate the workstation and other systems associated with the potential incident.
- Not turn off the power to any of these systems.
- Make an image of the state of each system, make a copy of the disk contents, and especially make a copy of the logs of all relevant systems.
- Then begin their forensic investigation
Of course many forensic situations could have been mitigated at the preventative stage by computer users / bacteria hosts following simple security best practices. But that is an ongoing conversation.
Have a secure week.
Regards, Ron Lepofsky, CISSP
President,
ERE Information Security and Compliance Auditors
www.ere-security.ca
Tags: DNA, Forensics, Information Security, IT Security, Personal Identification
Posted in Security Postings | 6 Comments »
Wednesday, April 28th, 2010
You may have read this recent survey conducted by ISACA or the article about the survey posted on CNET April 7 or the more recent article about access and authentication headaches for cloud computing published by SC Magazine April 9.
The message is clear: Remote users watch out for security and privacy threats! Of course there is absolutely nothing new about this message. But then again, there is very little that is new about cloud computing. Only its name.
Forty years ago cloud computing had other names: service bureau computing, remote computing, mainframe service providers, to name a few. Fast forward and we have similar shared services more widely accessible by orders of magnitude because of ubiquitous Internet availability and the flexibility of IP addressing. So the concept of a remote service provider has changed not in the least; one person in their basement running a great application on an NT server with worldwide Internet access is an example of cloud computing.
The security and privacy vulnerabilities are commensurately more serious than legacy service bureau operations with remote access provided typically by dedicated lines. (Anybody know or remember what dedicated lines are?)
The ISAC survey does pose the financial rewards vs. the potential downside costs of risk, with a nifty Risk / Reward Barometer visual. To read the article please see www.ere-security.ca RSS feed, April 7. The idea of doing a risk analysis and BIA on any critical service is nothing new in the security business and, of course, these tools should be used when considering the use of cloud computing.
Further, in my opinion, using a cloud computing resource is much the same as outsourcing an IT service. Any conscientious purchaser of outsourced services should consider, review, and have in writing as part of an SLA, many issues surrounding IT security compliance monitoring, enforcement, and a mechanism for recovering financial losses due to breach of the outsourcing agreement.
For more ideas about how to deal with an IT services outsourcer, please see: www.ere-security.com , IT Security White Papers, Risk Analysis, “IT Security Costs: Outsource vs. Self Deploy”
But I digress.
The fundamental business needs for enforcing access privileges and stringent authentication do not change whether the IT services in question are in-house or in a cloud, as pointed out in the SC Magazine article. By the way, you can see the article at: www.ere-security.ca RSS, April 9.
The issue of who is doing the access and authentication processes is critical to its control. I personally prefer the client retain control, and provide access to employees or users via a proxy service, again under the control of the client. The authenticated users should then be provided VPN access to the cloud based service provider.
However, this is all for not if the security framework of the cloud service provider is not up to snuff, and essentially circumvents all the good works of access control and authentication done by the client. Which brings us right back to the point about the degree of security agreed to and provided by the cloud service provider.
The bottom line here is: The catchphrase cloud computing is new but all its old security headaches aren’t!
Have a secure week.
Regards, Ron Lepofsky, CISSP
President,
ERE Information Security and Compliance Auditors
www.ere-security.ca
Tags: Cloud Computing, Information Security, IT Security, Security Risks
Posted in Internet Security | 5 Comments »
Wednesday, April 21st, 2010
Am I reading an oxymoron in this title? Or what!
In a recent article in CNET news, Elinor Mills investigates potential new security vulnerabilities by adding smart metering onto our legacy North American electricity distribution architecture.
First of all North America has not fully implemented a smart electricity architecture or “Grid”. A smart grid would not have allowed the type of cascading meltdown that occurred in August 2003, and as far as I know that grid has not been sufficiently modified as to be considered ubiquitously smart. Has anyone got a different perspective on the status of the grid upgrade? For a look at this article please click to: http://www.ere-security.ca/index.php , RSS feed, April 9, 2010.
The issue with adding smart meters with IP addresses does not compromise the security of the rest of the smart grid, in my humble opinion. This would be more of an issue if many key devices on the grid had IP addresses and were managed accordingly. But again, a smart IP grid is not there yet.
The CNET article goes on to explore the possibility of the smart meter’s being compromised and the countermeasures being implemented by various vendors. I’ve even read some articles identifying concerns that smart meters are possibly an entry point into a household’s network for hacking purposes. This sounds like dark magic to me, especially if the smart meter is in no way connected to the household’s network. The bottom line, I believe, is that smart meters in and of themselves do not present a security threat or a vulnerability to the grid.
However…….
Opening the control technology used by electrical distribution networks to a wider network certainly does pose a plethora of threats to the control technology and, therefore, to the entire control network.
The electrical distribution industry has standardized on SCADA control technology, and SCADA networks are sacrosanct. They control and monitor actual electrical equipment, and errors can result in death, damage to equipment, and power outages. So opening a SCADA control network to encompass smart meters expands access points exponentially. For more information please see http://www.ere-security.ca/SCADA_CIP.html
The problem then becomes securing the vastly greater scope of network against all the usual security suspects. The utility industry relies on a security standard called NERC CIP http://www.ere-security.ca/NERC_CIP_Compliance_Audit.html
In our experience as security and NERC CIP compliance auditors, we’ve seen nightmare scenarios regarding the unauthorized access vulnerabilities just on SCADA networks. I don’t want to give anybody any ideas, so I’m not going to be any more specific here. But you get the idea. If it is difficult as is to keep SCADA networks secure, imagine expanding the scope of access to the network by hundreds of thousands of locations.
My idea is that a smart grid is one with superbly controlled access and authentication. Access and authentication controls of course are composed of: logical controls, physical security, and people behavior. So some smart meters are the least of the worries for ensuring the availability and dependability of a smart grid.
Have a secure week.
Regards, Ron Lepofsky, CISSP
President,
ERE Information Security and Compliance Auditors
www.ere-security.ca
Tags: Information Security, IT Security, SCADA, Smart Electricity Architecture, Smart Grid
Posted in Information Security | 5 Comments »
|
|
