My Church Security – Church Security Plan Template

The core starting point of designing and implementing a security department or fraud department is to “level-set” where you are today with a SIMPLE inventory.  One of my most asked about tools is available FREE on the site.  There is a MS Excel version, Mac Numbers version of the file and How-To Video.  As I get feedback on the template/checklist, I will be updating it.  My hope is it is SIMPLE and should take no more then a hour or 2.

The core use of the template is to have your security focal point (that could be the person in the mirror) start by completing it to the best they can/have knowledge then gather information he/she is not privy to.  The key is to be brutly honest here with yourself.  The initial goal is to get it in a form to take the first DRAFT to the senior leadership.  There may be reviews along the way, but the key to success of baselining the organization is to make sure it is reviewed WITH the elder/deacon/overseers board.  Don’t just forward the (partially) completed template to them via email and say, “hey what do you think”……bad idea. Get in a room face-to-face and be honest.  This is not meant to solve world hunger, its meant to get everyone on the same playing field.

The left side of the template is general functions that MAY or MAY NOT exist or be needed.  The need for each function will be discussed in future blogs.  The top columns are guides to establish your organizations level of knowledge (of the existance or need) and maturity of each area.

Pull the file down and listen/watch my boring video and just get started.  Again don’t worry if you don’t understand a particular technical term, eventually we will get every row completed.

Subscribe to our awesome mailing list to receive our free template

? The Scope – “Logs fail to secure networks”

Another post in my ? The Scope series:

This is not meant to target the author or the vendor or the publisher of the content in question. Thus why I purposefully don’t link to the article. My issue is how we (looking in the mirror), as security professionals and security vendors, continue to try and educate a wide audience of (non-security) people with words and terms that are confusing and technically inaccurate or incomplete and many times not practical across the audience we are addressing and even borderline deceptive. Nevermind F.U.D. factors.

———————————————————————————–

I read a recent article that said “Logs fail to secure networks” – It was a good overview and I understand the spirit of what is being said/sold…..but….I ? The Scope. (Fighting for all the little logs in the world…..)

The author is advocating use of PCAP (technology), which I’m good with, but to make it sound like logs are significantly less valuable then PCAP, problem. I also hope he didn’t mean NetFlow…..allow me to ? The Scope:

“Why logs fail to secure networks”

1. A person I highly respect, once said a profound statement: “Networks were meant to pass traffic, not do security” so unless “networks” was defined by the author, I would disagree with his statement. Logs were never designed to ‘secure a network’ that isn’t meant to be secure in the first place.

2. Securing a technical environment (systems, devices, applications, software, network transmission stuff, etc.) requires, as we all know, a strong combination of preventative, detective, and corrective controls. Logs are critical to securing an environment in the detective control arena.

“logs rarely support an effective response to ….APT.”

Without a definition / scope of the author’s term “logs”, I would disagree. Properly configured and secured and reviewed logs many times are MORE effective in response to an APT (Threat = “Intent” remember, but that’s another post). PCAP capture (and NetFlow) in “a large enterprise” is usually setup in a way that it ultimately becomes a SAMPLE of traffic, a very valuable SAMPLE if the scope of the coverage is comprehensive.

“logs are prone to sabotage”

1. Sure if you don’t secure them to the same confidentiality, integrity, and availability controls and policies you enforce for all your other critical data….

2. Maybe not cost effective at some scale, but I have seen people just write the logs directly to DVD-R or equivalent read-only media. Simple solution and tada, limits the vulnerability of “sabotage”. Let’s not forget about PROBABILITY here. I just met a vendor recently that their primary product is highly scalable, high integrity, 100 year data (log) retention.

3. So PCAP logs / storage aren’t “prone to sabotage”?

4. Hackers usually aren’t that good to cover ALL their tracks (if they actually knew where their tracks were kept). And they are usually are coming to get something or place malware, their not planning on coming back usually….call it passive information theft….

“logs [are] a dubious source of information when the issue at hand is an advanced threat”

1. First thing when I have a system / application / device compromise is getting all the admins to secure whatever logs they have available. Can I trust the integrity of these logs? They are what they are. Would I ask for PCAP (and NetFlow), sure, but the likelihood of significant historical PCAP for a specific victim environment is much lower then system/application/device logs.

2. Will I verify the scope and integrity of the logs during my incident response process, absolutely.. Will I verify the same for the PCAP/NetFlow data, even more, yep.

3. Threat = Intent not compromise

“But there’s one thing a hacker can’t exploit. And that’s the wire.”

1. Wow, guess that rules out an insider with a pair of scissors.

2. So MitM attacks aren’t an exploit. Oh sorry, Jim, he said “wire”, not traffic.

3. Saving that quote for my next seminar. Good one.

“PCAP has the unique advantage of being completely inaccessible to hackers when properly implemented”

1. “completely” is a pretty all inclusive word, that’s putting a lot of trust in the vendor, or sysadmin of the PCAP capture infrastructure.

2. Logs also “have the unique advantage of being completely inaccessible to hackers” when properly implemented

3. Taps are never vulnerable either right?

“physically isolated network enclave”

1. Not very practical in a distributed enterprise (my definition)

“Applications write just enough information in their logs to support diagnostics”

1. Correct, if you configure them that way. Applications can also be configured to record EVERY keystroke and EVERY screen and replay them. Not sure a SAMPLED PCAP can match that. PCAP replay isn’t exactly perfected.

“produces a source of information that is incomplete and sometimes vague or irrelevant to an incident response investigation”

1. For 20+ years of doing incident management/response, I haven’t found a properly configured log and many times not so properly configured log, that wasn’t incredibly valuable to the response. By the way, just the identification that the log is not properly configured, is hugely valuable to the risk awareness of a victim organization/person.

2. I have also found that many times PCAP, to be completely useless also. That data, many times brought NO context or able to establish what is historical normal for how an environment operates.

“every byte”

1. Anyone out there collecting “every byte”……

“gives incident responders a complete, forensic view into the state of the network at any time”

1. E-N-C-R-Y-P-T-I-O-N = problem with PCAP, let of a problem for logs

2. “forensic”, as it, let’s take this PCAP data to court, really

3. state of the network – anyone visited an enterprise NOC lately….that’s the state of the network.

“Logs are expensive to manage”…..”PCAP may require a more expensive storage solution”

1. No comment

“When you switch to PCAP, you manage between one and a dozen sensors as opposed to a hundred applications”

1. The article started with working with a “large enterprise”…..so a large enterprise will need a maximum of a “dozen sensors” thus we only need to collect from a dozen network taps. And a “large enterprise” has just a “hundred applications”. Wow, need to rethink my definition of “large enterprise”

2. How’s those 10Gig Taps coming….

“Ultimately, logs are diagnostic tools for systems and applications. They are not security tools, and they will not facilitate an effective response to a breach”

1. Speechless. If that is the case, just turn off all the logs in your “large enterprise” for lack of security value. Let me know how that movie ends.

BTW: “Threat’ = intent, not actual compromise. and I would want Logs+PCAP+NetFlow if I had a choice.

Please security professionals (looking in the mirror myself here) and security vendors, let’s pause before we write this stuff and ? The Scope

Jim

Serving Ministries To Help Churches Stay Safer With Simple And Proven Solutions