Friday, December 18, 2015

Cybersecurity Fundamentals – Top 3 Project Papers.

After reviewing roughly 30 projects, these are my top 3 for the semester. There's another one that also I absolutely love about insider threat anomaly detection. I've included the summaries below of each of these well-written papers.

First, Lance created a survey asking users about smartphone security. Population size 117, statistically significant with a +/-10% margin of error. Contains interesting findings highlighting differences between Apple and android users. Great writing style.

Next, Harrison decides he's interested in learning about the dark web. He also has a great writing style which made this a fun and interesting read. Check this one out.

Finally, Seyed dove into Amazon Web Services security. I'm well aware of the wealth of information he had to go through to put this together, and I'm proud of the outcome and effort.

Head on over to the documents tab to view!

Smartphone Security Assessment

Lance Giles

In 2014, my laptop fell victim to a Basic Input Output Operating System (BIOS) rootkit, which left it irreparable. My good friend who ran diagnostics on the laptop and discovered the rootkit recommended that I start shopping for a new computer. The news that my laptop was not responsive to repairs stunned me. My use of the internet was limited to emailing, banking, shopping occasionally, and monitoring my credit. I had active antivirus and antimalware software on my laptop. No unusual behavior was detected in my laptop until it seemed abnormally slow one day. How could my laptop be penetrated by a rootkit that nestled in the BIOS when my usage was low risk and security measures were in place? When I discussed my puzzlement with my friend, he highly recommended that I visit Security Investigative Reporter Brian Krebs’ blog at ‘’ and learn more about malware, firewall, identify theft prevention, and mobile device security.

Since then, my interest in acquiring tips and techniques for securing information systems has accelerated. My interest drives me to evaluate the current practices of securing smartphones. To me, it seems that smartphones are rapidly becoming more commonly used than a laptop, desktop, or tablet. As of April of 2015, approximately 64 percent of “American adults now own a smartphone of some kind, up from 35% in the spring of 2011. Smartphone ownership is especially high among younger Americans, as well as those with relatively high income and education levels.”(3) Similar to laptops and desktops, smartphones are vulnerable to malware transmitted through emails, web traffic, and external media such as USB; however, unlike laptops and desktops, they are also vulnerable to malware transmitted by text messages, apps, and games. (6, page 40)

Into the Heart of Darknets

Harrison Van Riper

America has developed a fascination with the dark web. In the first season of House of Cards, one of the characters accesses the dark web to get in touch with a hacker. In dramatic fashion, he is introduced to the shady and covert services on the internet underbelly. Over the last couple of years, Silk Road has gained high media attention. The site provides an anonymous marketplace for drugs to be sold to its’ anonymous user base. The public perspective of the dark web is that it hosts all kinds of vile and illegal activities, like the aforementioned Silk Road or illegal pornography. I thought to myself, how can something so seemingly criminal exist? I’d never accessed it before or talked to anyone who had. Why not dig in and see what all the fuss is about?

Public Cloud Security (AWS)

Seyed Ahmadreza Amin

Information security is of paramount importance to Amazon Web Services (AWS) customers. Security is a core functional requirement that protects mission-critical information from accidental or deliberate theft, leakage, integrity compromise, and deletion.

Under the AWS shared responsibility model, AWS provides a global secure infrastructure and foundation compute, storage, networking and database services, as well as higher level services. AWS provides a range of security services and features that AWS customers can use to secure their assets. AWS customers are responsible for protecting the confidentiality, integrity, and availability of their data in the cloud, and for meeting specific business requirements for information protection.

This article describes best practices that customers can leverage to build and define an Information Security Management System (ISMS), that is, a collection of information security policies and processes for their organization’s assets on AWS. Although it is not required to build an ISMS to use AWS structured approach for managing information security that is built on basic building blocks of a widely adopted global security approach will help customers improve organization’s overall security posture.


Tuesday, December 15, 2015

IT Auditing – Mandarin Chinese Version

Thought this was really cool. Package came in the mail today with a book written in Mandarin Chinese... Thought at first it was a mistake! It's the last edition we wrote of IT Auditing: Using Controls to Protect Information Assets!! McGraw-Hill Education had the book translated and sent us a copy. Awesome!

Thursday, December 3, 2015

Wednesday, December 2, 2015

Asymmetric Defense Failures

No. I'm not talking about the cost of an attack vs. the cost of defending the network. I'm talking about traffic flows. Communications are bidirectional, ingress and egress, yet many still focus on only ingress protection mechanisms.

You need both. For example, your firewall and intrusion prevention system (malware, etc.) may do a fantastic job at identifying incoming attacks. However, you also need egress detective and protective controls. For example, your DLP system can help identify data exfiltration – egress – and your network behavior anomaly detection appliance can help identify potentially compromised hosts communicating to command and control servers.

There's actually much more to write about on this topic. But for now, suffice to say that intelligent context and control of communications are important from both perspectives.

Monday, November 23, 2015

NIST SP 800-53 r4 to CJIS v5.4 Control Mapping

Reverse mapped CJIS control set into NIST 800-53 controls as the new baseline.

Download here.

State Security Model Flaws – or… Assumptions

This is meant to be a short, simple post. Just capturing interesting discussion from our class the other night. The state security model is really simple, representing an easy way to describe the importance of governance. Provision, configure, validate to a known good state. Monitors state deviations. Known state deviations are good and mean that you are still in a known good state. Unknown state deviations must be investigated (response) to determine whether it is a new known state deviation or an incident.

However, some really good points were brought up during class. There's a lot of assumptions on external factors introducing the errors from the way that several people have presented and discussed the model. We learned this model in the military, and the source of the deviation could be assumed to be internal or external. It didn't matter.

The reality is that your definition of a known good state may or may not be absolute (100%). Your visibility into the system is almost certainly not absolute. Examples include running firmware, existing compromise, individual configurations, account access, authenticator systems, cipher code/implementation/system, source code, system interoperability/API configurations/capabilities/hidden capabilities...

If we presume that assurance of a known good state is based upon a selection of points that you can validate, then how many points are good enough to provide assurance of a known good state? What about the periodicity? Is there anything here we need to consider?

Systems themselves could *possibly* introduce errors within the bounds of allowed operations. People most certainly can. Component visibility can inhibit your view/understanding of actual state. Your view/understanding of actual state can change between timed points of inspection. External and/or internal actors may identify vulnerabilities in code and exploit that within the bounds of your controls.

The point of the discussion is that models can be very powerful, and certainly helpful for understanding systems through a particular lens. Think outside the box. Don't be afraid to ask questions. The person who initiated the discussion is perhaps one of the least technical people in the class, just asking innocent questions.

How do you address the concerns? Short answer. Build the system with enough introspection and visibility into critical processes/configurations that overcomes your risk tolerance. Make the assumption that the system is already compromised and build it so that you can identify an existing compromise to the extent possible. Strong emphasis on access controls, not repudiated auditing, visibility into communications including who/what/where/why/how/volume.

Spreadsheet: FBI Cloud Control Catalog – Appendix A

Here's the spreadsheet version, cleaned up, of the FBI Criminal Justice Information Systems (CJIS) Security Policy - CJIS Cloud Control Catalog.

► Download spreadsheet version here.

Friday, October 30, 2015

HIPAA Technical Control & Assessment Links

Go to the documents tab to find spreadsheet versions of the below.
Recent discussions… Capturing some of that here. Some of the more important links to technical assessment information is above. Services are actually easy to build, as long as you simplify the approach. Has everything to do with scope, stating assumptions, and setting expectations.

By the way – yes, I downloaded and reviewed the current version of the HITRUST framework.

On another note, HITECH  has nothing to do with technical controls and is an unfortunate name. It's confusing, but it's entire focus is enforcement – putting teeth into HIPAA using financial penalties as an incentive. Please do not use it out of context.

Friday, August 28, 2015

Still Relevant – Sales Engineering Lessons Learned

Found a document where I captured some of the quick lessons I learned experienced in the first year working as a presales engineer. 9 years later, these are still relevant.

SE Lessons Learned
  1. Be genuine. You have to learn who you are and be comfortable. It really doesn’t matter what you’ve done or who you know. When you’re in front a new customer, they don’t know you, and you are beginning from scratch. It’s OK to befriend them, and you should, but…
  2. Develop relationships slowly. This isn’t a race to be the most likeable guy. Take your time. Be accessible, be open, make friends, but in the end you have to make the sale. Never lose sight of your end goal or you will become ineffective and too involved to make decisions.
    • This isn’t a buddy-buddy game. It’s about genuinely helping someone with a project and helping your customer to close a sale. This means…
  3. Don’t spill the beans. Let the customer learn what they need to know slowly. This does two things and prepares you for the next point.
    • First, the customer needs the information they believe is most important to them. Although, there is an education component of the sale, you have to address the pieces that are most important to the customer. Regardless of why they believe what they believe – They do, and you have to address that first.
    • Second, the customer shouldn’t be overloaded with information they don’t care about. It’s nice that you know your field so well, or that you anticipate a question about something down the road. Carefully scope how much information you give them, and they can continue coming back to you for more. It’s not about withholding information – it’s about not giving away the cards completely.
  4. Never talk down to your competition. It’s great that you have a superior product. If you don’t, then you should move to a company you believe in. However:
    • You don’t know these people as well as you think you do, where they come from, who their friends are, or what competition has a particular feature they actually see as superior. It doesn’t matter if they are right or wrong in their own assumptions. They have friends and opinions and you have to respect this. Instead of bashing the competition…
  5. Consider alternatives to talking down to your competitors. This doesn’t mean you can’t say a word. You can express an opinion:
    • Offer to go head to head during an evaluation and absolutely speak to your previous successes going head to head. Let your actions speak louder than your words.
    • Speak to your product’s strengths and not against specific product weaknesses. Speak to weaknesses broadly as a class of product if you’re asked about it.
  6. Ultimately, you have to focus on the end-result. Sell product.
    • Your job isn’t about making the best documentation possible, the best friends possible, or doing anything else that doesn’t contribute to the bottom line of your success. Perfectionists beware. It’s good to have drive and work hard – but spend the energy perfecting the sales process, not anything else that takes time from you taking care of current customers and helping your sales manager get into more accounts.
  7. Nobody cares how much you know. People want to know how much you care. Try to understand the customer’s problems and spend time recognizing the strengths of the people you’re working with. They will learn how good you are over time.
  8. Communicate. As much as the technology you know, your role is in sales.
    • Stay in touch with your sales manager and escalate issues to him before he’s blindsided with an account that he thinks is going well.
    • Stay in touch with your sales channel counterparts. Other SEs should:
      • think of your solution when they visit a customer
      • speak to your solutions strengths
      • defend your solution when challenged in the competitive landscape. 
  9. Read books. You don’t know yourself and others as well as you think you do. Learn what others are interested in and read a book about it. Read about sales. Read about relationships. Read about your industry or a new technology. Read. Read. Read.
  10. Under promise and over deliver. Always do this. Develop a reputation for delivering on what you promise. This builds trust faster than anything else. You need to finish a few tasks well – not perfect – rather than fail miserably in trying to complete several tasks.
  11. Never underestimate politics. Political relationships drive important decisions whether you are involved in the process or not. Some people will like you as long as you are useful to them and don’t get in their way. Nobody likes to be overshadowed. People want to know you are willing to help them and will back them up. When you start doing well, the way you handle your success will determine the reaction and support of those around you that aren’t doing as well.

Friday, May 8, 2015

Machine Learning – Intelligent Security Data Analytics

Ran across a fascinating TED video which provides insight into just a close we are to meaningful security data analytics.

Machine learning systems within the last year now process images, signs, and information with more accuracy than a human. The extraordinary Deep Learning algorithm allows scientists to build learning systems without prior knowledge of the subject and solve previously unsolvable problems. Unsolvable… not because of computational power limitations… but because people don’t know how to solve the problem. The machine, however, can learn about and figure out new ways of solving problems that people have not yet thought about. This is different from programmatically writing the logic for how to solve problems.

Consider speed and analysis of system operations with accuracy and capability beyond what a human being can process, scaled to consume the entire output of the data centers operational output (errors, logs, alerts). This is beyond building rules to identify bad traffic and malicious events. This is about enabling a deep learning machine to read every known book, website, web forum, data feed, dark web content, and become a security powerhouse with ultimate knowledge of your data center.

Sound crazy? Far-off? Watch the video below.

Jeremy Howard

Monday, March 30, 2015

The Emerging Recognition of Governance

Thank you Verizon. Fantastic report. The authors did a wonderful job and my hat is off to you. Thank you Dark Reading. Thank you twit.

Governance really is THAT important.

Security used to look something like this… Then organizations started to focus on compliance when Sarbanes-Oxley and in PCI became mandatory and prevalent. Security professionals realized that compliance in and of itself wasn't enough, and the focus shifted to addressing risk. Problem is that people still feel like they are playing Wack-a-Mole. The governance problem started becoming… A problem. It grew geometrically with the number of different new systems, vendors, applications, interconnections, interfaces, and dependencies.

During the lifecycle of the system there are different security and risk challenges that must be solved, such as those described in context of a PCVMR Cycle, which recognizes the importance of maintaining the system over time.

Let's look at operational hygiene, or governance, in the lands of a state security model. You start at the 0 when the system has been validated/authorized for operations. Ideally at that moment in time the system is fully secure without any flaws. You've tested the system against known attacks and established that the system is properly secured to your baselines. Over time, however, the adjusted state for where you should be is a slight trajectory upwards with some growth to recognize changes in security posture/configurations, architecture, design, firmware, patches, control inheritance, additional solutions, etc.

Compare the state of where you should be vs. the day 0 configuration and what you find is that over time you have a greater gap. Let's call this current state vs. secure state gap "drift". The drift/gap gets larger over time, and leaves you susceptible to compromise. Now go back and look at the wonderful statistics the Verizon team put together and read the column in red.

Does compliance = security? Depends. Depends on whether you recognize a properly implemented risk management framework as necessary to meeting the compliance requirements. Depends on whether you recognize compliance requirements must be managed over time. Depends on whether you have the right people who understand, processes that enforce, and tools that execute and track governance of your systems.

Tuesday, February 10, 2015

Discussion of SCADA and Multitenant Environments

Here's a reminder that a technical control failure can be driven by management/administrative and/or governance failures. Recently, a conversation focused on multitenant environments handling very different data types and sensitivities.

I would not put SCADA/PLC power distribution control systems on the same physical frame as consumer payment processing or anything else externally accessible. It's not simply a matter of whether the system can be secured. It's a matter of who is ultimately responsible for the security of the system. The security of the system is going to be hard enough. If there is confusion as to who is responsible for system security, then you significantly increase the likelihood of control failures from system drift over time.

Thursday, January 22, 2015

"We've got you covered!" Be careful. Be very very careful.

Very interesting day today listening to a vendor discuss how they have security covered. To hear them speak, you would think that they have covered security from soup to nuts. In ways that you can only fathom imaginable.

Read the fine print.

Better yet. Read your authoritative sources, risk management process findings, and understand your own requirements.

Three years ago I enrolled my little boys in MMA classes. They enjoyed it so much that I very soon got them started in private lessons with a professional UFC fighter. What I found to be fascinating was that despite his repertoire of tricks and experience, he often went back to the basics of what was necessary to succeed in a fight. Sure, the extra stuff can take you over the top. But if you don't understand the fundamentals, you're setting yourself up for failure.

Security is the same way. You can look at all of the new bells and whistles on the market, but if you can't execute on the fundamentals, you're setting yourself up for failure.

Perhaps one of the more interesting moments I've had in this industry came when a friend simply said to me, "Chris, this doesn't have to be that difficult. As long as you can control access to the data, you win. Every time."

On the surface of it, this is true. However, executing this idea is more than just access controls. He knew this, and that led into the discussion of the different vectors which were either a path, or gateway component, for access to the data and exfiltration of the data. The network is a critical piece of this architecture, and absolutely must be secured with appropriate access controls, intrusion prevention, network behavior anomaly detection, etc., etc..

Other things to consider include endpoint protection, log collection, log analytics, data loss prevention, and other controls that identify a potential compromise in the secure state of your system security. Don't lose sight of the big picture. Keep in mind the comprehensive set of controls necessary to protect access to data, inclusive of context. Subject. Data object. Paths. Demarcation points.

Remember technology affects every part of the infrastructure. At its best, security is a competitive differentiator. At its worst, security is your competitors differentiator.