policy question

tedjamestedjames Scruffy-looking nerfherdrMember Posts: 1,145 ■■■■■■■■□□
Do you know of a policy or standard, preferrably NIST or similar, that concerns the physical location of an information security team within an office? Essentially, we're looking for something that states that a security team should be located behind a locked door, segregated from IT and any other group. Thanks!

Comments

  • aftereffectoraftereffector Member Posts: 525
    If there is such a stipulation in NIST, I haven't seen it. I can't speak to any other standard though - I've only dealt with DIACAP / NIST environments.
    CCIE Security - this one might take a while...
  • soccarplayer29soccarplayer29 CISSP, CISA, PMP Member Posts: 230 ■■■□□□□□□□
    I don't know of anything like that.

    The closest I can think of it the NIST 800-53 MP and PE control families but they don't cover that. As it relates to your question the MP controls discuss how media should be handled, stored and protected where the PE controls discuss how access to facilities should be controlled and that only authorized personnel are permitted. But there's nothing related to the segregation of the IT security team from other groups/entities to my knowledge.
    Certs: CISSP, CISA, PMP
  • cyberguyprcyberguypr Senior Member Mod Posts: 6,882 Mod
    NIST SP 800-61 makes some reference to war rooms and secure storage facilities. Maybe you could leverage that. This document also provides some guidance for standing up SOCs that covers physical elements.
  • TechGuru80TechGuru80 Member Posts: 1,539 ■■■■■□□□□□
    How about the concept of need to know? How can you protect information if anybody can come up and see what you are working on or hear what you are talking with the team about? That is probably the simplest argument.
  • tedjamestedjames Scruffy-looking nerfherdr Member Posts: 1,145 ■■■■■■■■□□
    Thanks for all of the great information! The MITRE document is fantastic, and NIST 800-53 PE is pretty close. We are definitely using the concept of need to know including incident handling. Our IT Director is asking for specific NIST citations when making our case. He gets it, but we're still having to convince non-security types of our need for privacy. Always an uphill battle...
  • PJ_SneakersPJ_Sneakers CompTIA, EC-Council, ISACA, (ISC)², Microsoft USAMember Posts: 879 ■■■■■■□□□□
    Do you handle any type of forensics where you need to secure physical devices? If so, you might be able to use SWGDE's guidelines for digital evidence labs.
  • Danielm7Danielm7 Member Posts: 2,287 ■■■■■■■■□□
    I'd love to find something obvious. I was able to get my seat moved to a more private cube as I had my back facing the hallway and had to do employee investigations. At my job only the management gets actual offices with doors, grumble grumble. Even then my gear is all over my cube, they did manage to get the forensics stuff setup in a storage room off the server room that is secured but I still don't love cubes.
  • markulousmarkulous Member Posts: 2,394 ■■■■■■■■□□
    I thought there was something in NIST or another standard that stated that any privileged info couldn't be seen by anyone walking by. Or maybe it was just a vague FISMA requirement, I can't recall.
  • tedjamestedjames Scruffy-looking nerfherdr Member Posts: 1,145 ■■■■■■■■□□
    Do you handle any type of forensics where you need to secure physical devices? If so, you might be able to use SWGDE's guidelines for digital evidence labs.

    Unfortunately, we don't do forensics here. That would certainly help our cause.
  • tedjamestedjames Scruffy-looking nerfherdr Member Posts: 1,145 ■■■■■■■■□□
    At my old agency, we had been working in a SOC for five years with privacy for days until the new CISO decided that we needed to be in the main office so he could be closer to the execs. So I went to cubicleland. I got a nice cube with my back to the door in the contracts department. Had to get privacy screens until I could move to a better cube with two real walls. Still, I had to have phone conversations at very low volume so the contracts staff couldn't hear me talking with the other agency security departments about their penetration test results or current incidents. Sure, the contracts people may not have known what an IP address was, but that was beside the point. I was always cautious about protecting this kind of info, but at that point, I had to be twice as careful.
  • tedjamestedjames Scruffy-looking nerfherdr Member Posts: 1,145 ■■■■■■■■□□
    markulous wrote: »
    I thought there was something in NIST or another standard that stated that any privileged info couldn't be seen by anyone walking by. Or maybe it was just a vague FISMA requirement, I can't recall.

    Thanks for the tip. I'll see what I can find related to FISMA.
  • dmoore44dmoore44 Member Posts: 646
    You might be able to use a data classification standard to categorize active incident information at a higher level than operational information, and then as @cyberguypr alluded to, use another NIST pub to justify using a secure storage facility as a separate space.
    Graduated Carnegie Mellon University MSIT: Information Security & Assurance Currently Reading Books on TensorFlow
  • TheFORCETheFORCE Senior Member Member Posts: 2,298 ■■■■■■■■□□
    A lot of the standards and policies are vague on purpose so that they can be applied to various scenarios and so that those who follow the standards can implement the controls by different means. As an example, the below quote is taken from DoIT. As you can see, they state that any confidential information should be protected with 3 types of safeguard, administrative, technical and physical. Since they mention "physical" it is implied that if someone is working with confidential information that person should be in a location with other people that work on the same type of information, if they are not, then you are not using physical safeguards. By being vague, they can apply the policy to different situations as times change.

    "Confidential information should be protected with administrative, technical, and physical safeguards to ensure its confidentiality, integrity, and availability and to prevent unauthorized or inappropriate access, use, or disclosure." http://doit.maryland.gov/publications/doitsecuritypolicy.pdf

    Policies and standards are like that, they are open to interpretations so they can be applied in different situations.
  • tedjamestedjames Scruffy-looking nerfherdr Member Posts: 1,145 ■■■■■■■■□□
    dmoore44 wrote: »
    You might be able to use a data classification standard to categorize active incident information at a higher level than operational information, and then as @cyberguypr alluded to, use another NIST pub to justify using a secure storage facility as a separate space.

    YES! Very nice, thank you.
  • tedjamestedjames Scruffy-looking nerfherdr Member Posts: 1,145 ■■■■■■■■□□
    Excellent example, thanks!
    TheFORCE wrote: »
    A lot of the standards and policies are vague on purpose so that they can be applied to various scenarios and so that those who follow the standards can implement the controls by different means. As an example, the below quote is taken from DoIT. As you can see, they state that any confidential information should be protected with 3 types of safeguard, administrative, technical and physical. Since they mention "physical" it is implied that if someone is working with confidential information that person should be in a location with other people that work on the same type of information, if they are not, then you are not using physical safeguards. By being vague, they can apply the policy to different situations as times change.

    "Confidential information should be protected with administrative, technical, and physical safeguards to ensure its confidentiality, integrity, and availability and to prevent unauthorized or inappropriate access, use, or disclosure." http://doit.maryland.gov/publications/doitsecuritypolicy.pdf

    Policies and standards are like that, they are open to interpretations so they can be applied in different situations.
Sign In or Register to comment.