Stories of a CISSP: High Security




Two black Chevy Suburbans effortlessly drove through the cold mountains, crunching the snow underneath its vulcanized rubber tires.


"Sir, we'll be on the main road for about 30 minutes, and the another 40 minutes through the mountains. If you need anything just let us know."


"Hey thanks a lot man, appreciate it". I seriously thought about asking if they happened to have a vomit bag? I just got off a plane and was still a bit woozy.


It was an indescribable feeling to be driven around by two ex-military personnel (1 driver, 1 riding shotgun) in the middle of the night to my final destination: a multi-million dollar state-of-the-art data center located up an icy road. My plane landed just an hour before and I was asked to meet my Director at the data center right away - I had only just slightly recovered from the air sickness - I hated flying.


There were refreshments in the SUV in the middle console and I helped myself to a Ginger Ale. The 35% tinted windows made outside visibility non-existent, I glanced out the front windshield to make sure at least the driver could see the road up ahead. He didn't have the high-beams on, so I made myself feel better thinking he already knew the road pretty well.


But, this whole thing isn't as cool as it sounds. It was a fake reception. A ruse. A deception to impress potential clients who wanted to tour the data center and the security operations center (SOC) facility of the organization. There was a certain "image" my company wanted to exude in order to nail a lucrative contract.


The black SUVs were leased. The refreshments in the car were probably months old (the selection of Ginger Ale probably meant this car was for airport pick-ups and provided for anyone experiencing my current health predicament). The realest thing so far about the entire experience was the military backgrounds of the two silent professionals in the car. But even then, they weren't private military contractors or anything, they were just the company nightshift security guards who spent what looked like about 10 hours in the gym everyday. However, if there was a certain "look" of those that have kicked down doors in foreign lands with a rifle in their hands, these guys had that look. Glad they were on our side.


And here was me, a network security engineer who weighs 170 lbs soaking wet, being DRIVEN around like some sort of VIP. But again, in reality, the company was just too cheap to get me a rental car and decided to make use of the company car instead. Still, it was all very impressive. They even called me "Sir"!



Upon arrival to the data center building, we had to have our photos taken and submit our fingerprints to a biometrics scanner. Now, even when going to the CISSP testing center, I really did not like the feeling of providing my biometric information. So out of concern (and to flex some of my CISSP study knowledge) I asked the testing proctor what the data retention was for my palm scan per Pearson VUE corporate policy. The proctor didn't flinch and responded "We erase your biometric data after 90 days". I had to take her word on it.


At the data center, I once again wanted to ask the security guard the same question, but decided to forego my curiosity. The timing just didn't seem appropriate. Whatever the answer was, what was I going to do about it at this moment? Nothing. So many three-letter government agencies had my information anyway. I would have to find out from my manager the corporate biometric data retention policy.


It would be a different story however if I were a citizen of the European Union.


The United States does not have a unified federal privacy regulation on biometrics (there may be some at the state level). But Europe does, and it's called the General Data Privacy Regulation (GDPR) - which just happens to also be an important CISSP topic.


When the GDPR went into full effect in 2018, the new legislation applied to mostly all countries in the European Union. They classified the processing of biometric data as prohibited for half a billion EU citizens, unless because of the following: explicit permission given, pending employment status, protecting the individual who cannot give consent themselves such as in the case of public health, or legal matters.





Some other facts about biometrics involving the GDPR:


  • Even if explicit consent is given for biometrics data, EU citizens have a "right to be forgotten" and can withdraw consent. At this point the biometric data processor will have to remove the biometric information from the system.

  • If there is a breach of biometric data, the user has to be notified within 72 hours of breach discovery.

  • While an actual breach does not constitute a penalty or fine, a company may face legal ramifications if they didn't perform proper due diligence to secure the biometric data.

  • If any company around the world processes European citizen data, they are subject to the laws of the GDPR.

  • Biometrics play a heavy part in the formation of GDPR legislation.


We were then given a badge with a photo-ID and a smart token. To access secure areas of the facility we had to first scan our badge and then scan in our fingerprints - this was Two-Factor Authentication (something you have and something you are).


Right after going through the mantrap and just before the nondescript doors to enter the actual data center cages and racks, I was steered toward the conference room where my Director was already sitting on one of the side tables swiping through his phone. He saw me come in and got up and made his way to shake my hand. A respectful gesture from a higher level senior leadership member.


"How are you Luke? It's been awhile. How was the flight?" He asked perky as can be for being 11PM in the middle of the night.


"Good, good. It's good to be back in this part of the country, it's a different scenery that's for sure" I said thinking of the blond from the plane.


"Yes, definitely a lot more mountainous part of the coast here. Did you like your airport service?" The Director was always proud of the cloak and dagger type presentation setup for clients to be impressed with the company.


"Ha, yes. It felt very VIP, thanks for sending the car. Both gentlemen were professional as always." I really had nothing else to add. I was tired. I was a bit lightheaded. I just wanted to get back to my hotel, take a shower, check the Facebook Group for pending posts and direct messages, and just pass out.


"Great Luke. Let's have a seat I won't take up too much of your time at all, just want to go over what is expected for tomorrow. Please feel free to help yourself to the cold subs in the fridge over there, they were leftover from the meeting with some of the Japanese folks earlier this evening."


I hadn't realized how hungry I was and purposefully walked over to the small fridge and pulled out the first sub I saw wrapped in a clear film saran wrap. I recently stopped eating pork for religious reasons, but at this point, I was so hungry I didn't care. Actually I did, but rolled the dice hoping it was either beef, chicken, or a veggie brand. It was a Mediterranean chicken sub, nice!


Wolfing down the dinner my Director and I continued our conversation for my purpose of being here this week:


My trip out West was to take part in the development of a new security event management platform. We were creating a unified online portal where we could see all our customer tickets, engagements, processes, device information, passwords, SNMP logs, and vendor updates - it was a big deal. I wasn't so much part of the development aspect but rather part of the User Acceptance Testing (UAT). The developers were going to go over the general design and development of it, but after deployment, it was the security engineers who were going to interface with it on a daily basis. An internal certification and verification stage had to be completed before it hit a live running production environment. Along with the engineers, a few other representatives from other departments were also present to provide input or further questions on the software usage and requirements.


After the Director and I were done, I proceeded to egress out the data center the same way I came in, surrendered my badge, went through the mantrap again, and was dropped off at my hotel. An all black Chevy Suburban pulling up to a hotel in the middle of the night drew some eyes from those smoking cigarettes near the designated areas. I went to my room, answered emails, and forgot all about that extra chicken sub sandwich I grabbed out of the conference room and left it on the hotel room counter until the next morning. What a waste.





The next morning when introduced to the software engineers of the new system, we learned the development team used the Agile software development model. While not a coder, I was able to recall from my CISSP study guides that the agile method is an improvement over the Waterfall and other software development methods because it allowed for flexibility. Additionally the agile method also required a lot of diverse teamwork, continuous feedback, incremental and iterative methods.


I came to understand the need for a unified security event management platform was driven by senior management in a top-down management approach. This means that all organizational decisions and strategies are the sole responsibility of senior management as they drive the company.

In a large conference room with 20ft long tables nearly pushed up against wall, I was sitting closest to the entry door. The building had no Wifi as a security measure, everyone had to be hard-wired into the network. This evaded the question of "What's the Wifi password?" and prompted the question "Where are the Ethernet cables?"


The room consisted of the development team, some managers, a project manager, and a few security engineers. This was it. This was the team that was supposed to develop a brand new system which will be the flagship product that we will provide as a selling point to potential clients. This was what I dreamt of as a systems administrator years ago, to find a security job where I did actual security things that helped to change or move a company forward. It was intense, it was difficult, and everyone had to be bring their A game, either contribute or get out of the way.


I knew I could do it. I had my CISSP. I knew what it took for me to get that CISSP, the discipline, the hard work, the effort - all that empowered me to handle whatever real life security threw at me. The CISSP sustained me like the Dark Side sustained the Sith.


There were a lot of questions being thrown around and directed so I'll just point out the ones focused on my team of network security engineers:


  • What are some of the important things you guys need to first address and maintain with your customers?

  • What do you need to maintain and address with your fellow security engineers?

  • What are you looking for with this new global platform?


I had a lot of time to think about this on the flight over, that is, when I wasn't looking at the gorgeous blond in the aisle seat of business class. And her eyes were as blue as the azure sky visible out the plane windows. She reminded me of my wife, who probably would have appreciated the view as well.


I spoke up first just because I wanted to get my participation grade out of the way. "We would like a few things, just about the same things we have in the current system platform. We need customers to be able to see our updates in the portal. If needed, we need them to have the ability to approve changes, which means they need to see our updates quickly. We need to be able to have a running clock that we can start and stop so our work hours are appropriately logged per customer. We also need a place where we and the customer can upload files securely, so that we aren't emailing VPN configurations and pre-shared keys back and forth."


"Definitely Luke definitely," said the long gray haired programmer reminiscent of the Area 51 scientist from Independence Day movie (who also happened to play Data on Star Trek, Brent Spiner). He continued pointing the business end of a pencil at me, "What about the firewalls themselves? What aspects of their operation need to be seen through the portal for better efficiency and customer engagement?"


"Sure. We would need all that we have now: IP addresses of all interfaces, ping checks, SNMP status, high availability status, a history of the tickets associated with the firewalls for at least a couple of years, log server IP addresses, the SSH public keys, and...ummm..."


My colleagued picked it up. "We need to know all customer NAT IPs as well. The NOC usually provides the NAT mappings, but we'd need to know that. In the current system, we just know the public facing IP and have to do a few other steps to figure out what private addresses they hide."


The SOC team lead was at the table and piped in "Which means that the development team has to obtain a list of customer NAT mappings from the NOC, since the SOC doesn't have a complete list. We do have them, but the NOC can provide that information more readily". The team lead was thinking like a manager. Of course the SOC had all the NAT mappings, but we'd have to spend extra time and effort going through each customer firewall configuration to find them all, while the NOC would have a readily available list since they were the ones who assigned them.


"Sounds good guys, anything else?"


A solid hour of conversation later it seemed like the dev team wanted to move on from the technical aspects of the platform to the business requirements.


The engineers all looked at each other and agreed that would be good for now, there was still a long way to go. The dev team was using the Agile software development model after all, changes could be made along the way if necessary.

Now, I just wanted to go over a few of the business requirements for this new system as that is the key of "thinking like a manager" for the CISSP exam.


The service delivery manager asked "Will we be able to see how many change credits a customer has left before they submit a change?" Change credits were what was used to measure and track each change to a customer device, meaning they got charged every time they submitted a change. This is in essence all about managing cost. The organization wanted to know how much the customers were paying or were supposed to be paying. And the customers got to see how many change credits they had left before submitting a change. This way, there was no question on either side as to who had to pay what for what work and at what time.


The sales manager asked "When can we officially tell new clients this platform is available? And when can we tell current customers that they have to migrate to the new platform?" This was also about revenue but also to keep customer relations intact. Sales wanted to quickly tell new customers about this new fantastic platform and lure them in to manage their security. At the same time, the sales team also didn't want to destroy the relationships they had with current customers because it was going to be a hard sell to get them to migrate from their old platform to the new one. With the new platform, the old customers had to migrate to it, they had no choice. And as we all know, nobody likes change, much less a complete infrastructure change, especially when things are running smoothly.


And lastly, some of the internal administrative staff had questions as well "What would you say is the learning curve for this new platform?" The non-technology oriented employees were a bit nervous to learn a completely new software platform. This meant they'd have to go through not only the proper training, but also the additional security awareness training that came with it. At this point, the developers tried their best to tell them that the new platform will be intuitive and purposely kept simple for not only regular users, but those in the technology department as well. I.T. is not as easy to everyone as it is for us. As a manager, it is best to have everyone trained on not only the software, but the security aspects that came with it.


We wrapped up the week with more fine-tuning of software requirements. If I were to say how all this related to the CISSP software development life cycle, it would be the following:


Source: NIST 800-64


  1. Initiation

  2. The initiation, scope, and policy of the new system development occurred many levels above my current position and pay grade. These were done in high-level meetings with not only regional directors but also the global executives. The only thing the network security engineers saw of this stage was an email from the top management team about starting a new platform and their positive attitude about its future for the company (and of course, the world!). The policy stated they wanted the company to make its mark in the industry with this new platform and to be a major player in the security market.

  3. Basically the company wanted to leave its old ways of doing things and wanted to introduce a new streamlined way of doing business.

  4. Development/Acquisition

  5. As this was software built in-house, it was being developed and not acquired. My trip out West was part of the development phase were functional business leaders, users, and the developers worked together to come up with the software requirements.

  6. Risk assessments were continuously conducted, security requirements were analyzed, security architecture was designed, and initial documents for certification and accreditation were prepared.

  7. Implementation/Assessment

  8. The new platform did take off and worked as expected. There were of course some troubleshooting and missing functions because of the scale of the systems, but these are currently being ironed out by post-development teams.

  9. There was a good bit of work to make sure the new information system worked in the current production environment.

  10. Security controls of the system and other interdependencies were also tested.

  11. Operations/Maintenance

  12. At this point it was standard to use a complete change and configuration review of all changes to the new system and all other systems which interact with it 24/7.

  13. New processes and procedures were developed and old ones were fine-tuned and updated with proper documentation.

  14. Disposal

  15. The system is still live and has not yet met the disposal phase. Hopefully that doesn't happen anytime soon!

  16. If disposal were to happen, some security considerations first and foremost would be to have a formal disposal plan.

  17. Maintenance of an archive to house critical information and remove them from the system to reduce data remanence

  18. Sanitization of media.

  19. The eventual disposal of hardware and software


There is no major point to this story of a CISSP, just wanted to show how daily work in the security industry always seems to have a small component of our CISSP studies. Being a CISSP doesn't mean you have to know everything about all the domains, it means that you have to know just a little bit about everything. Which is why the actual exam tests you on just a little bit about everything.


Thanks for reading.


CISSP Take-Away Concepts


Domain 1: Security and Risk Management

  • General Data Protection Regulation - An EU legislation that affects and protects the private information for all EU citizens. Even though it applies to the EU, it also applies to any business in the world that processes EU citizen data.

Domain 2: Asset Security

  • Data retention - Asking about the amount of time biometric data will be held in storage is inquiring about its data retention period. It is best that first there are limits to collecting private information, and then even better to hold it for a limited amount of time and not forever.


Domain 4: Network Security

  • Ping checks, SNMP, pre-shared keys, NAT IPs - These are all components of network architecture to move traffic from one place to another.

Domain 5: Identity and Access Management

  • Biometrics, badge, mantrap, 2-factor authentication - these are all forms of confirming identity and authentication in order to access a facility.

Domain 6: Security Assessment and Testing

  • Security awareness training - Users require awareness training to not only be aware of potential social engineering and network attacks, but also to reduce the number of potential mistakes made on their part.


Domain 8: Software Development Security

  • Agile development model - Allowed changes to the system if needed throughout the development process. Inputs were provided from various functional leaders and users.

  • User Acceptance Testing (UAT) - Those who will actually use the new system had their inputs provided and will eventually test the system before deployment.

  • SDLC Stages and Steps - If preparing for the CISSP exam, one must know and understand not only the stages of the SDLC, but also how security mechanisms are enacted within each step.

Click here to read other Stories of a CISSP.

STUDY RESOURCES

"How To Think Like A Manager for the CISSP Exam" 

Now available

on Amazon Kindle! 

As an Amazon Associate I earn from qualifying purchases.

As an Amazon Associate I earn from qualifying purchases.

MEMBERSHIP
  • 231+ CISSP VIDEOS
  • 700+ PRACTICE QUESTIONS
  • PDF NOTES
  • 1,250 FLASHCARDS
  • TELEGRAM GROUP
  • MONTHLY
    EMAIL UPDATES
  • $29.99 per month
  • $74.99 3-months
  • $144.99 6-months
CRACK THE EXAM
LEARN ABOUT

© 2013 Study Notes and Theory
Terms and Conditions/Privacy Policy

Proudly created to make you

a better security professional.