The pen test we do through Nessus is passive, our goal is to identify and report the vulnerabilities we find and allow you to close the holes and harden your systems. A majority of vendors find passive pen test results sufficient but some require active pen test results. We don’t do active pen testing because of the risk and liabilities involved. – Recent Communication From A Security Vendor
Who shall remain nameless. There is a difference between penetration tests and security vulnerability scans. The two do not meet. Neither does an admission of a passive pen test or an annual security vulnerability scan being acceptable to the majority. I’ve never heard those words in the same sentence.
This kind of misinformation to score the deal is ugly. Not only is it a risk to the organization writing the check, but it’s your reputation on the line for signing the deal. Only good security people will see through this…
“As Albert Einstein is often quoted as saying, ‘If I had 20 days to solve a problem, I would spend 19 days to define it.’ So the first question you need to be asking is, ‘are you asking the right questions’? – 137 Security Questions Every Leader Should Ask. (2013, September 9). In SecurityIntelligence
As we finish up our SOC2 audit, these security questions run concurrent with everything we do as a security practice and a security leader. This is one of those articles I refresh upon every now again because it’s exactly on message.
There are no laws preventing a bank or credit union of using the SS# as a bank ID. (The government remved the verbiage indicating that the SS# cannot be used as identification sometime in the 70’s.) It is just a bad idea… for a few reasons, based on a conversation I was in with legal experts. Here are those notes:
1) It is considered personal identifiable information (PII). PII could include:
Name: full name, maiden name, mother’s maiden name or alias
Personal identification numbers: social security number (SSN), passport number, driver’s license number, taxpayer identification number, patient identification number, financial account number or credit card number
Personal address information: street address or email address
Personal telephone numbers
Personal characteristics: photographic images (particularly of face or other identifying characteristics), fingerprints, or handwriting
Biometric data: retina scans, voice signatures, or facial geometry
Information identifying personally owned property: VIN number or title number
Asset information: Internet Protocol (IP) or Media Access Control (MAC) addresses that consistently link to a particular person
Using the SS# as the customer identifier makes this information more accessible to contractors, vendors, and others that require access to the account but not the PII. (Thin about how you are accessing your bill payment vendor. You will be passing the customer identification number. Hence you are now providing a SS# to a third party vendor.)
2) Speaking of third party vendors…you must consider how they use the customer identification number. Fiserv sometimes embeds the ID in the transaction number. Now the SS# is exposed elsewhere. I have seen other payments transfer vendors do similar things. Customers get a little sensitive about this sort of thing.
3) You now have the SS# is two places on your system. While you may contain your PII differently, the customer number is generally not considered PII. You will be forced to consider this with every interaction – printed reports, statements, etc.
4) It’s not unique, and its not even a very good identifier. The most infamous case of that was 078-05-1120, which was used on a sample Social Security card by a wallet manufacturer. At one point, more than 5,700 people were using that number as their SSN.
This is an excerpt of an email I sent to our employees. I am proud to be a part of this organization change and milestone with Lanvera’s IT department.
We Are All ITO
Historically, “IT Operations” was one department, one team, all functions. This model hasn’t made sense and wasn’t positioning this department to scale to the next level. Since May 2017, we’ve seen more than a few organizational changes, restructuring functions, and changing of personnel roles. Now the dust has settled, it’s a good time to mention our brand and mission for this year.
My team’s theme for 2018 is NIHIL SINE MAGNO LABORE. Latin translation is “Nothing Without Great Effort”. Steve talks a lot about our IT transformation, having achieved much, but have more ground to go. The phoenix seen here is representative of our transformational journey. I would like to extend this theme to all IT teams as we pull together.
To this aim, all teams fall under the department “ITO” and break out into three separate teams: Infrastructure, DevOps, and QA. Moving forward, teams will be identified as “ITO – Infrastructure”, “ITO – DevOps”, and “ITO – Quality Assurance”, respectively. The goal is unification of technology services and support.
“Learning is a treasure that will follow its owner everywhere.”
— Chinese Proverb
There is so many things IT people need to know these days. Gone are specializations in many organizations. Yep, IT pros must know 20 to 30 different types of technologies to remain relevant and competitive. In fact, as I interview younger candidates, there is evidence the new generation of IT people already have these skills and more.
And that’s just infrastructure. All organizations expect IT people to know core business applications. Specifically, how they relate to the organization and customer, technical work flows, monitoring, and on and on. How does an organization tackle it all while keeping IT pros at least tuned into the periphery?
How I’ve done this historically is this idea of knowledge culture and DevOps’ “Sharing” idea, where team members present material via a TED talk. Below is my deck on peer learning. I hope you find it applicable.
“If you fail to plan, you are planning to fail!” – Benjamin Franklin
January marks the six months and our progress is moving rapidly on multiple fronts.
1. Developed and publicize IT’s strategic plan for 2018. This is our road map for the year, developed in December and approved by senior leadership.
2. Workstation Technology Refresh is in full swing. Moving to Windows 10 has been fairly uneventful and user satisfaction is high with the hardware decision. Although we’ve made a conscious decision to stay with legacy software productivity platforms so we can have more time considering Office 365.
3. VMWARE NSX progessing slowly. Primarily, due to difficulties with our network provider, a subject for a future blog. Mobius has been fantastic and working with my local team. Concurrently, team members are spinning up on NSX via VMWARE’s training classes.
4. SOC2: AICPA’s Service Organization Control 2. SOC 2 is considered a technical audit, but goes beyond that. SOC 2 requires companies to establish and follow strict information security policies and procedures, encompassing the security, availability, processing, integrity, and confidentiality of customer data.
5. Knowledge Management and ORC. Hard push getting Operations Readiness Checklists for all production systems to serve as the foundation of our KM system.
+++ If you read this far, you may be wondering if this is an old post. Yes. It was never published, along with the other 30+ posts in various stages.
Speaking strictly of Patrick Lencioni’s vision of Death By Meeting, the strategic meeting is the hardest meeting to get off the ground. Although, I argue it’s the most critical. At LANVERA, we’ve succeeded at stand up and tactical. Easy parts. Now, onto strategic…
“NIHIL SINE MAGNO LABORE”
– Translated ‘Nothing Without Hard Work’
Rebuilding technology is no small feat. It takes people who are willing to work the extra hours, have the attention to detail, put their technical skill to the test, and work with peers who expect the same. It takes a team.
IssueTrak is a fairly basic ticketing system currently in use at LANVERA. Although development efforts surrounded IssueTrak giving it a level of criticality to the business, we found ourselves painted into a corner with this solution. We cannot upgrade without risk of breaking our applications. That is on us.
However, my biggest concern was the product wasn’t designed with ITIL or any ITSM framework in mind, in my opinion. And I wasn’t sure it ever would be with their track record of mostly bug fixes and focus on non-service management features.
As a result, in September 2017 I met with IssueTrak’s leadership to discuss the roadmap of IssueTrak . Here is the deck I prepared for that meeting.
The conversation was mostly positive and there was a healthy agreement that the product wasn’t developed with these use cases in mind. I hope the product continues to mature and grow as competition in the ITSM space is healthy in the SMB space.