In my previous article, I tried to cover why metrics are an important part of your security program and some of my beliefs about how metrics should be created and used.

I am often asked about what specific metrics I collect, what metrics are important to my trustees, and how I report on them. I will try to present this information, with the proviso that metrics, like everything else in security, are not one size fits all. You have to make sure that you always take into account your environment and the appetite that your business has for risk.

Let us start with some information you will need to build your metrics. I am a strong believer that metrics should be presented as a normalized number or percentage. For example, saying that we had 37 compromised systems last month can mean two completely different things depending on the total number of systems that make up your environment. A small shop with only 200 machines would have a compromise rate of 18.5%, while a shop with 90,000 systems would come in at 0.04%.

You will need to know:

1. Number of systems – Total and # compromised/time period
2. Number of network nodes
3. Number of employees and, if different, IDs – number of compromised accounts/time period
4. Count of systems by OS and versions

As you start building your metrics portfolio, I would highly recommend that you automate the collection process from the beginning. Building the display for this type of metric (number or counting metrics) is straightforward once you have the data. Collecting the data without any automated process will prove to be both onerous and time consuming. While some of these counts may have been static in the old days, with BYOD and IoT, the days of fixed machine counts are long gone.

This is a sample of some counting metrics that we collect and display automatically. This is a live dashboard, fed by analyzing netflow data in real time. This is also a sample of what I would classify as “security theater” metrics, meaning that while they are pretty pictures, the value of them is low because we can do little to change these numbers since the computers generating them are not under our control.

We do send emails out to the owners (ISP) of the compromised systems (including logs and brief summary) letting them know that they are hosting hostile compromised systems.

Before the world turned into a global economy, you may have been able to get away with blocking all traffic from a country with which you did not do business. However, the world today makes the Castle and Moat type of security impractical. There may be as much, or even more, “good” traffic from a “bad” country, making blocking all traffic a bad idea.

The world map in our dashboard shows the numbers of IP addresses from the country launching specific attacks against our network. The Attacks by Incident Type shows the kinds of attacks that we are monitoring (we look for over 80 different types of attack behaviors).

The next layer of important metrics to develop are based on your risk management program. IT Risk management is, in simple terms, a process by which a system is analyzed, certified against applicable policies, and then approved. The risk management process is complicated and would require a much larger article to explain.

According to National Information Assurance Training and Education Center, risk assessment in the IT field is:

1. A study of the vulnerabilities, threats, likelihood, loss or impact, and theoretical effectiveness of security measures. Managers use the results of a risk assessment to develop security requirements and specifications.
2. The process of evaluating threats and vulnerabilities, known and postulated, to determine expected loss and establish the degree of acceptability to system operations.
3. An identification of a specific ADP facility’s assets, the threats to these assets, and the ADP facility’s vulnerability to those threats.
4. An analysis of system assets and vulnerabilities to establish an expected loss from certain events based on estimated probabilities of the occurrence of those events. The purpose of a risk assessment is to determine if countermeasures are adequate to reduce the probability of loss or the impact of loss to an acceptable level.
5. A management tool which provides a systematic approach for determining the relative value and sensitivity of computer installation assets, assessing vulnerabilities, assessing loss expectancy or perceived risk exposure levels, assessing existing protection features and additional protection alternatives or acceptance of risks and documenting management decisions. Decisions for implementing additional protection features are normally based on the existence of a reasonable ratio between cost/benefit of the safeguard and sensitivity/value of the assets to be protected. Risk assessments may vary from an informal review of a small scale microcomputer installation to a more formal and fully documented analysis (i. e., risk analysis) of a large scale computer installation. Risk assessment methodologies may vary from qualitative or quantitative approaches to any combination of these two approaches.

(Source: NIATEC Glossary of terms)

For the purposes of this article, let us assume that you have a risk management process in place and can assign a risk value to the systems that have gone through the assessment. To make this simple, we can use a scale of High, Medium and Low. Our metric would look like a list of systems organized in risk order from High to Low. You may want to build a heat map as I’ve mentioned before. You should include in the presentation the mitigation controls needed to reduce the risk. You should make sure you have calculated the resources needed to implement those controls.

Organizing your metrics this way will give your Board the information they need to either allocate the resources required, or to accept the risks. Make sure that you are prepared to answer any detailed questions they might ask about the risks as well as the process used to determine them.

I am sure that these articles will generate more questions than answers. I view that as a good thing, because metrics can be used to answer those questions. Remember, there is no single answer to all of the questions, but metrics is what you should use to get the answers.

The post Using Metrics to Improve Your Security Program – Part 2 appeared first on Security Current.

So…you are responsible for the computer security of your organization. You probably have many great ideas on how to do this. You start looking around for products and services to implement those plans of yours and figure out quickly there are no commercial solutions that fit into your budget. Now what do you do?

Enter Metrics—the solution to all your problems (well, not really, but this is an article about Metrics). Back in 2008, I wrote an article published in the Educause magazine called Security Metrics: A Solution in Search of a Problem. Rather than rehash that article since you can read it yourself, I will start with the final tag line and proceed from there: “Metrics are the answer, now go and find your questions.”

One problem that metrics can help with is procuring resources to build your security program. Many organizations have either a small security department, or they view security as a “second job” for the members of the network group. I am confident that anyone involved in security, full or part time, is fully aware that, in many cases, we are losing the war. You will find yourself in trouble at some point unless your security program is growing and changing.

Security metrics will reveal the maturity of your security program. Here are the four steps to organizations process improvement, from James Harrington’s book The Improvement Process:

Measure: If you can’t measure it, you can’t understand it.

Understand: If you can’t understand it, you can’t control it.

Control: If you can’t control it, you can’t improve it.

Improve: The final step: Now go back to the first step—Measure.

Metrics or measurement is the first step needed to improve your security. There is a saying “if you can’t measure it, it didn’t happen.” I have a saying about security: “If it didn’t happen, you probably have a job tomorrow.” In either case, metrics will be the key to unlock the funds needed to improve your security program.

When starting off down the security road, the metrics that you collect will be what I refer to as “counting metrics” – they usually start with the idea of “how many”:

1. We had 40 compromised systems last month.
2. We had 25 compromised user accounts last week.
3. We met with 200 users and did training last year.

These metrics are a great place to start. They will demonstrate that your security program is producing measureable results and allow you to grow your program by using them as justification for additional resources. For example:

1. With better protection, we should be able to reduce the number of compromised systems.
2. With multi factor authentication, we will be able to reduce the number of compromised accounts.
3. With more people or an online training program, we should be able to train more people and make that training more effective.

I believe that all metrics that are collected should allow you to enhance the program being measured. I do not believe in using scare metrics. Stating that 500,000 spam messages were blocked is a useless piece of information since you really cannot do anything to change that number. The amount of spam (or viruses) that you receive is a function of the internet, not something that you have any control over.

In my mind, I measure the value of a metric by evaluating if it can be used to improve security. I like to think that we (the good guys) are at war with the bad guys. There is a phrase “OODA loop” that applies very well to using metrics to improve security:

“The phrase OODA loop refers to the decision cycle of observe, orient, decide, and act, developed by military strategist and United States Air Force Colonel John Boyd. Boyd applied the concept to the combat operations process, often at the strategic level in military operations. It is now also often applied to understand commercial operations and learning processes. The approach favors agility over raw power in dealing with human opponents in any endeavor.” (Source: Wikipedia)

I liken it to a thermostat: metrics measure the current security environment and tell the security team how the controls are working.

Once you have built your security program to the point where you are entering the measurement phase, an additional piece of the security puzzle is governance—the political structure of your organization, and to whom the security team reports. It is my opinion that many organizations have a broken governance structure. The security team reports somewhere in the IT organization and therefore is in direct competition with other IT functions for resources. This may mean that if there is a choice between fixing payroll and fixing security, you can bet that payroll will always win. From my perspective, security needs to report as high up in the organization as possible, preferably to the Board.

At Columbia University, we have a hybrid reporting structure; we work both for the VP of IT (CIO) and also report quarterly to the Board of Trustees. This means that security needs to produce metrics that will be of interest to the board as well as in a format that is meaningful.

You should make sure that the reports you create are designed for the audience that will be consuming them. As the presenter, you will need to know all the details behind the pictures. When a high-level view is needed, you should make sure that you are not including all the facts and figures.

As time goes on, your metrics should show that you are building a more secure environment. This should trigger a change to add a risk-based security component to your security program. Looking at risk-based metrics will show how your programs are preventing incidents, rather than counting the number of fires that you have extinguished.

Doing risk management in the IT world is complicated and time consuming. It involves knowing the value of information (data classification), where the data is being stored (servers, desktops, under peoples desks, etc.), how the data is being accessed (web or fat clients) and many other details that can be used to calculate a risk score.

Risk metrics will typically show assets and the associated risk score by group, often in the form of a heat map:

“A heat map is a two-dimensional representation of data in which values are represented by colors. A simple heat map provides an immediate visual summary of information. More elaborate heat maps allow the viewer to understand complex data sets.” (Source: Whatis.com)

In conclusion, I believe that metrics should be considered a tool for process improvement, not an end in themselves. Generating pretty pictures should not replace understanding the underlying facts that the pictures represent. Make sure that the metrics are a true and meaningful picture of the process being studied. Remember to always sanity check your findings. Only you can prevent metrics abuse.

About the author: Joel Rosenblatt is Director, Computer & Network Security at Columbia University. He has been working in IT for over 39 years, the last 17 in Computer security.

The post Using Metrics to Improve Your Security Program appeared first on Security Current.

The first week of March in 2017 will be remembered as the time that AWS (Amazon Web Services) failed. The actual failure was in the Amazon Simple Storage Service (S3), but to the world in general, if your stuff was running in the Amazon cloud, it was not working.

Amazon provided a very complete write up of what happened, which basically boiled down to someone made a mistake, which caused a cascading failure that required several systems to be restarted in order to get the S3 system back up and running.  Amazon is making some changes (read sanity checks) in their systems to prevent this type of problem in the future.

Within 24 hours, I started receiving advertising emails from companies asking if we suffered from the Amazon outage and would we like to look at them to prevent this from ever happening again. In Yiddish, we would call this chutzpa (audacity).

Along with my security prime directive “There is no such thing as perfect security,” the corollary system rule is “There is no such thing as a perfect system.” I am a firm believer that given enough time, every system will eventually fail. What we need to work on is the ability to detect the failure and then recover quickly. We should always learn from the failure and build controls into the process to prevent the same failure in the future.

At Columbia, we use a system that was written here that looks for compromised systems and automatically takes them off the network. In addition to using behavior analysis, we get feeds from various places that help us find systems communicating with known bad actors.

Back in 2015, one of these feeds sent us a false positive and, as a result, our system mistakenly took hundreds of computers off the network. Now, in this case, although it was not a local mistake that caused the failure, to the owners of the computers it was a local failure. As a result of this, we added a circuit breaker into our system that will pop if hundreds of systems instantly show up with exactly the same problem. Sometimes, even the best automated system requires a human.

While I essentially believe that it is impossible to build an effective security system without at least some automation, my experience tells me that any system needs to have sanity checks built in and, at the very least, a way for humans to override the process. These fail safes can take the form of white lists, circuit breakers or a simple on/off switch.

These simple cautions would ruin the exciting scenes of many an action movie (the scene opens on the hero crawling through the tunnel where the lasers are set to vaporize any rodent, ignoring the fact that rats are at least 100 times smaller than a person). In real life, you would want your anti-rodent security system to be able to tell the difference between people and mice – a sanity check sub routine.

As it appears to me, security threats are not going away or even reducing any time soon. Our best security tools will require smarter and smarter automated systems to keep up with the sheer number of attacks, even though many of these are designed to distract you from the real attacks hiding in the noise. Make sure that any system deployed has the intelligence behind it to tell the difference between a mouse and a person.

The post Is Your Next Security Failure One Fat Finger Away? appeared first on Security Current.

Normally, I would never talk about politics, and this story will not be an exception.  However, the analogy here is too good for me to pass up.

Let’s say that we are going into an election. One of the candidates Mr. T (I pity the fool), has continuously stated that everything has been rigged against him.  The problem I see with this is that whether this is true or not, the seed of doubt has been sown. The people who choose to believe that “someone” is out to get them are now primed and ready for the claim that “The election has been hacked.”

There is an excellent article by Steve Ragan about the feasibility of actually hacking an election, but to summarize it, the probability of actually changing the outcome of a national election is very, small.

Without going into the details of the attack mechanisms (you can read about them in the article cited above), lets dive into the probabilities.  While we like to think that when we cast our vote, and that the actual vote makes a difference, in truth the outcome of the election is decided by the Electoral College.

While it may be possible to hack an individual voting machine, especially those that use Direct Recording Electronics (DRE) used in Florida, hacking the Electoral College is not electronically possible.  The votes are collected by hand on paper, thus avoiding the possibility of remote hacking. In order to possibly change the result of an election, you would have to hack enough voting machines to swing the results of the popular election (not a simple task) and then have that capture enough electoral votes to create an absolute majority (270).

In a normal election year, there is usually a fairly clear picture of which candidate is leading “in the polls” – another thing that Mr. T claims is rigged.  This year, it appears that the result of this election will be a crap shoot.  I believe that this is a perfect set up for a huge mess come November 9^th.  Remember the election in 2000 and the hanging chads? The statement “The election was hacked” is going to make that look like a cake walk.

In the story of the Emperor’s New Clothes, the emperor was persuaded that the special suit he was given would be invisible to people who were unfit, stupid or incompetent.  He then went out parading in his birthday suit and all the towns people say what a wonderful outfit he is wearing.  A child finally speaks the truth, that the emperor is naked.

In my story, I think that we need to be the children and say loudly that the election is not hacked, the polls are not rigged and the system actually works.  It remains to be seen how many townspeople are out there.

The post Hacking the Election – The Emperor’s New Clothes appeared first on Security Current.

I read an interesting article the other day about a talk at DEF CON – Thermostat Ransomware: A Glimpse into the Future of Crime in Cities

It was about how the speakers did a proof of concept of a ransomware infection of a smart thermostat.  My first reaction (as a geek) was, “Cool!”  Then I started thinking about this. On the surface, the Internet of Things (IoT) is a great idea.  It will bring me one step closer to the world of The Jetsons (though I am still waiting for my flying car). Won’t it be great when your toaster, coffee maker and refrigerator can chat?

“I noticed that Joel was having coffee and a bagel for breakfast this morning, Yes, he usually does on Wednesday – I guess that tomorrow, he will want yogurt and blueberries” – at this point, the refrigerator chimes in – “I don’t see any blueberries in here, I guess I better contact AmazonFresh and have them drone in a box.”

You laugh, but I can see Jeff Bezos having this very conversation. I can see this happening in the future (maybe even in my lifetime).The problem is, as wonderful as this may be, the opportunities for abuse stagger the mind.

Going back to our thermostat, my hack would be to set the temperature either very high or very low (depending on the season), then encrypt the device so that it can’t be changed.  At this point, I would require a ransom to get it unlocked.  A few days of the heat coming up when its 90 degrees outside will send most people to the bitcoin bank to get control back.

Now, messing with your thermostat, while really annoying, is not the end of the world – for about $250, you can replace it and get your house back.  Lessons learned, always make sure you change all default passwords, and figure out how to install any updates to your devices that are available.

What worries me is that you can also break into many of the new cars using the WiFi hot spots.  I can afford to replace a thermostat, but if someone were to encrypt the brakes on my car, I would have a serious problem – I only hope that the dealer can reload the firmware and will not have to charge me for a new computer system.

As we move forward into the brave new world of The Jetsons (which aired September 23, 1962), we need to make sure that the merger of the real and virtual world does not leave us all standing in the dark saying “Jane, stop this crazy thing.”

The post What Happens When the Virtual World Becomes Real? appeared first on Security Current.

One of the most useful things to me in trying to secure an enterprise like Columbia University is information, and the more information, the better.  This means that for most of the time that I am not in meetings, I sit and read.

Most of my input overload comes in the form of emails, approximately 800 to 1,000 per day.  I don’t claim to read all of them, and a good number are vendor solicitations.  (As an aside, what is up with the vendors calling before sending out an email?  I’m up to almost 10 calls a day asking if it would be OK to send me a white paper on how their product will solve my problems. I guess they don’t want me reporting their email as spam.) Another non-trivial number are online magazines; these I almost always read, not cover to cover, but any articles that catch my eye.

Recently, I saw an article from Government Technology called How Terrorists’ Use of Social Media Points to the Future. I read it a few times to make sure that I understood the subtle message that the author was trying to convey.

Now, maybe I’m missing the point (I often do, just ask my wife – J ), but I sure did get the impression that the author was hinting around the idea that there should be some kind of system in place to censor what is being said on social media when the end result was terrorism.

To be perfectly clear, I do not support terrorism in any size, shape or form, and I do not believe that our media, social or otherwise, should be co-opted by the terrorists for their own purposes.  However, I do have a problem with censorship.

Social media is a very fast moving stream of consciousness, so the only way to effectively monitor and restrict its content would be to develop an automated system that would block content that was “socially unacceptable” in the eyes of (and this is where I have a problem) the programmer.

I may be going off the deep end again, but I do know a little about programming. The best systems for natural language recognition are far from perfect – once you start using them to shape the information flow, I believe, that you will be going down a road that I am not sure that many of us will want to be traveling on.

I personally like my information in as raw a form as possible.  I get my security email unfiltered, which is another reason that there is so much of it. One of my pet peeves is when I send a report to a security or abuse address somewhere about a compromised account that is sending us SPAM and I get it back telling me it was not delivered because it is SPAM … duh.

I really don’t have any problem with a post being taken down, by a human, when it is violent or an advertisement to join our cause and help us destroy society, but having an automated filtering system do this on the fly is a step that I would not want to take.

The problem with slippery slopes is that once you start sliding, it is very hard or impossible to stop.

The post Going Down the Slippery Slope appeared first on Security Current.

My friend Randy Marchany tweeted a link to an article “Millennials Value Speed Over Security, Says Survey”  that started me thinking about the apparent conflict between speed and security.  If you google “Agile software development,” you will see a Wikipedia page, which extensively covers the topic.

“Agile software development is a set of principles for software development in which requirements and solutions evolve through collaboration between self-organizing,^[1] cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change.^[2] Agile itself has never defined any specific methods to achieve this, but many have grown up as a result and have been recognized as being ‘Agile’.”

The interesting thing is, if you do a search on that entry for the word “security,” you will find that it is mentioned only once, under the section Regulated Domains. The section per the following consists of the areas where “agile development” is not appropriate:

“Agile methods were initially seen as best suitable for non-critical software projects, thereby excluded from use in regulated domains such as medical devices, pharmaceutical, financial, nuclear systems, automotive, and avionics sectors, etc. However, in the last several years, there have been several initiatives for the adaptation of agile methods for these domains.^[64][65][66]

There are numerous standards that may apply in regulated domains, including ISO 26262, ISO 9000, ISO 9001, and ISO/IEC 15504. A number of key concerns are of particular importance in regulated domains which may conflict with the use of agile methods:^[64]

• Quality Assurance (QA): Systematic and inherent quality management underpinning a controlled professional process and reliability and correctness of product.
• Safety and Security: Formal planning and risk management to mitigate safety risks for users and securely protecting users from unintentional and malicious misuse.
• Traceability: Documentation providing auditable evidence of regulatory compliance and facilitating traceability and investigation of problems.
• Verification and Validation (V&V): Embedded throughout the software development process (e.g. user requirements specification, functional specification, design specification, code review, unit tests, integration tests, system tests).”

I am not interested in becoming the security guy who always says NO, but sometimes you just need to think long and hard about exactly where you are going and what will happen when you get there.  The interesting connection between the article and Agile software is the dates – it appears that the same millennials who value speed over security are responsible for Agile development, which is not surprising when you think about it.

As someone who has been in this industry for over 40 years, I can say from experience that it is incredibly easy to make a very small mistake in a program and create a very large security risk.  Show me a person who never takes shortcuts when writing a program and I will show you an old guy (in this context, somewhere north of 35), or someone who has been burned before.

What scares me about this is that The Business has latched onto this Agile development as a way of boosting the bottom line – get the apps out there faster and we can make more money.  I am afraid that some of them may have missed the section on where Agile is inappropriate.

This brings me to the point of my tale: We need to be the champions of automation of security.  It is essential that the culture of security be baked into the SDLC and that we make sure that all of the developers out there understand that while it is great to be fast, the bad guys are faster. If there is a vulnerability in the product, the bad guys will find it.

When we stop doing security, people will get hurt.

It’s not the speed that kills, it’s the sudden stops.

The post Security: It’s Not the Speed that Kills appeared first on Security Current.

I was looking at Facebook the other day (yes, I know – a security guy that uses Facebook – just wait until you have grandkids and a scary message appeared at the top of the page. It was the 39 year anniversary of my employment at Columbia University.

I have been working in IT for 39 plus years (including the time as a student employee).  It occurred to me that while I have only been doing security for 18 years, all of my work in IT has revolved around one thing – Data.

In the 1992 election, Clinton used the phrase “It’s the economy, stupid” to focus the campaign workers on the importance of this message.  I would like to use “It’s the Data, stupid” to focus the attention of security on what is really important.

As I listen to various presentations (many by vendors) on “security shiny things,” it is amazing to me how few products are out there that actually protect data.  In my humble opinion, protecting the data should be job one, and the best way I know to protect data is to stop collecting data you do not ABSOLUTELY need.

I just got off the phone with someone who was telling me about a project that he was trying to squash. It involves collecting Personally Identifiable Information (PII) all in one place — including passwords and security question answers (everything short of SSN and bank account numbers) for employees. This way, in case someone leaves, they would be able to know where everything was.  The reasoning is that because of employee turnover, it is hard to keep track of everything.  They want this to be in a shared file, so everyone that needs the information could get it.

I don’t have to say how many things are wrong with this, but if you look around, you will find lots of these shadow systems – where a system could be as small as a sheet of paper (or spreadsheet) kept by the administrator.  Unfortunately, most of these are not encrypted or protected in any way, and unless you start looking for them, they will only be found by a misguided web click or a “I didn’t know that file sharing programs share ALL of my files.”

I often say that security is 10 percent technology and 90 percent politics.  Working with people is the most challenging and, I think, the most interesting part of the job.  One of the most useful security books I have read is How to Win Friends and Influence People by Dale Carnegie. Remember: people are just trying to do their jobs, and unless you find ways to enable them, they will find ways to get around your best security toys.

It’s the Data, stupid.

The post It’s the Data, Stupid appeared first on Security Current.

This seems to be the time of year that everyone is holding a security conference.  I will be attending eight from January through the end of April (and speaking at four of them.)

The interesting thing about most of these meetings is that they are usually sponsored by vendors, who believe that their product or service is the answer to all of your security needs.  This mentality that security is a “thing” that you can buy, and by installing it on your network, it will solve all of your problems is a fantasy worthy of Grimm’s fairy tales.

I think that the story of Little Red Riding Hood is a pretty good analogy to the current APT (Advanced Persistent Threat).  All of us Little Red Riding Hoods are walking through the very dangerous forest (the World Wide Web) – we are told to stay on the safe path (HTTPS, known URLs, safe web sites), but being a little curious, we may occasionally click on the sketchy link.  The Big Bad Wolf (nation states, organized crime) is out there just waiting for that click.

We all know that it’s not if we click, it’s when, so we will get eaten by the wolf.  The Hunter (the next Security Thing) comes to our rescue (sometimes they claim to stop the wolf, sometimes they just help us find the wolf and recover our grandmother and Little Red Riding Hood), but in the end, we are safe and sound, all thanks to them.

The reason that these are fairy tales is that they did not happen, but they are supposed to teach us a lesson.

My problem with this is that while all of these products may help with some aspect of security, none of them fix all of your problems, and many of them will generate so much work for you and your security team, that the real business will be buried under the millions of alerts.

Because I work at a University, it may be much easier than if I were working at a bank (if you believe this, I have some nice swamp land for sale), but I have always felt that security is a process and you need to have a philosophy to follow in order to create a secure environment.

My philosophy of security for Columbia is:

• Always remember that Columbia is a school and not a bank
• By protecting the world from Columbia  (i.e. locating and removing any compromised system on the Columbia network) we will protect Columbia
• We have complete control over our own network
• One size never fits all
• There is no such thing as perfect security
• Education and technology are equally valuable
• Always remember that you are in a people business

One size fits all security (buying the right Thing) is not effective because, in the end, there are many paths through the dangerous forest, and all of your Little Red Riding Hoods will not always stay on that safe path.

The post Security is Not a Thing appeared first on Security Current.

I guess it’s time to admit that I might be getting older.  When will the adults of the world take back the media and create a Bull S*** rating system.  We have a rating system for movies:

“Rated PG: Parental guidance suggested – some material may not be suitable for children. Rated PG-13: Parents strongly cautioned – some material may be inappropriate for children under 13. Rated R: Restricted – under 17 requires accompanying parent or adult guardian.”

I propose an additional rating for news items “Rated BS – People strongly cautioned – there is little to no truth in the following article.”

It appears that the district attorney of San Bernardino County, Michael Ramos has suggested that there is the possibility of a “Cyber Pathogen” in the iPhone 5c used by the terrorist.

I believe, in my opinion, that he may be watching TV a little too much (maybe CSI: Cyber) and could really benefit from that BS rating code.

I will be the first one to tell you that I like my Syfy channel, but at least I believe that I can tell the difference between reality and fantasy.

Well, enough writing for now, I need to go to the store and by that super strong umbrella for the next Sharknado.

The post First Sharknados, Now Cyber Pathogens – What’s Next? appeared first on Security Current.