TOPIC: Information Technology

Welcome to your DMZ

Much like the contested area that separates two foreign powers that do not trust each other, a network DMZ is a place where you stick things to don’t fully trust - like public facing servers, or even your service providers.  Yes, you have properly vetted them as part of your vendor management program, but depending on the relationship, you do not necessarily trust them with your institution’s network or all of your data.  For example, why would you want someone at your ATM service provider to have full access to your network and possibly your mortgage loan files? A firewall is used for more than just web filtering and protecting your organization from threat actors on the Internet, it is also there to help protect you from threat actors that may be lurking on networks with which you have a better trust relationship.  Firewalls protect your internal network from high risks associated with any other networks, not just the Internet.  And, that is usually where we find the DMZ: on the firewall. Typically, managed service providers (MSPs) like your core provider or the Federal Reserve for example, will ship you a router and some instructions on where to place it on your network, and what ports to open on your firewall.  No matter what these instructions say that device should go in the DMZ.  Sometimes these instructions are more like guidance than a bullet point how-to.  But this is where the planning and your responsibilities start, where you need to understand what interfaces you will use, source and destination addresses, and policies that need to be configured to restrict communication to only allow specific data flow between specific endpoints. Most of the time you already have all the hardware you need to make this happen - The only thing you might be missing is additional physical interfaces on your firewall.  Out of interfaces?  Fix it by purchasing an inexpensive unmanaged switch to hang off your firewall’s DMZ interface and plug in multiple MSP routers. To further support this design, FFIEC guidelines sum this up in two simple statements:
  • Financial institutions should use firewalls to enforce policies regarding acceptable traffic and to screen the internal network from directly receiving external traffic.
  • The DMZ is situated between the outside and the internal network and prevents direct access between the two.
In conclusion, even though you trust the vendors that directly connect to your network, no amount of due diligence is going to protect you from a configuration error on their part, or a threat actor or ransomware on their network.  Only physical and logical security controls can do that. If you feel that your firewall is configured improperly, or you just have a question, reach out to us.  We are here to help.

    BID ARTICLE: Inquiry & Insight: Compliance, AI, Strategic Initiatives

    Readers of the BID recently asked us about compliance management systems, AI to improve customer experience, and re-evaluating strategic initiatives. We provide our insight in today's article. Read Article

    Have a questions for Steve Brown or one of our specialists? Email your questions to steve.brown@pcbb.com or ask them in the comment section below. 

      Minding your P's and V's

      Congratulations!  Your boss has tasked you with creating a Patch Management Policy to address a recent IT Audit finding.  So, you think to yourself “no problem, I’ll just Google an example - or even better, request a template from 10-D Security and knock it out."  Just when you think this is the easiest thing you’ve done all week, your boss comes back and nonchalantly states, “Actually our remediation tracker says, ‘Vulnerability Management Policy’, so create that instead.”  “Ok, fine,” you think, “I’ll call it whatever you want, it’s the same thing anyway.”  Or is it? A quick web search for definitions reveals there is indeed a difference!  For more information on developing these policies as well as working templates see the blog post attached or on our website, https://10dsecurity.com/minding-ps-and-vs/ .

        Adobe Flash is almost done - time to purge!

        Adobe will stop distributing and updating Flash Player after December 31, 2020.  We shouldn’t be surprised by this news; Adobe gave us three years notice, and browsers have been yelling at us forever that Flash is nearing end of support and has been disabled by default.

        There’s been little need to download and install Flash for a long time, as Microsoft built it into Internet Explorer and Edge for years, and Google Chrome and Mozilla Firefox have as well.  Microsoft states that “Flash will be completely removed from all browsers by December 31, 2020, via Windows Update.”  Google and Mozilla have also noted that flash will be removed from their browsers in the same timeframe.

        It’s a good idea to identify if you have anything in use that requires Flash.  Some IT management consoles require flash (looking at you, older versions of VMware!) and some HR related online training services that haven’t been updated may require it as well.  It appears that it may be a significant problem to use Flash after end of life, as Adobe states that “Flash-based content will be blocked from running in Adobe Flash Player after the EOL Date.”

        If you have installed Flash manually, identify where and work to uninstall it.  Many patch management solutions will help you locate Flash installs.  Other software inventory tools, both free and commercial, can help as well.  We don’t necessarily recommend any product over another, but simple online searching will easily let you identify the major players to evaluate.  

        For more information, see https://www.adobe.com/products/flashplayer/end-of-life.html

          Security Disciplines

          Ah, security.  Network security.  Information Security.  Endpoint security.  Configuration security.  Cloud security.  Physical security.  There are subtle, but important distinctions between them, and knowing those can be the difference between having a good week and wishing you’d become an accountant.  This week we dive into the many disciplines of security in our blog,  https://10dsecurity.com/security-disciplines/ 

            The Role of IT in an Institution’s BSA/AML Model Validation

            Financial institutions of all sizes are using more technology to improve their processes.  For example, models can help an institution budget, price liabilities, and identify risks.   One particular model that has seen growth in the past few years is for BSA/AML monitoring. 

            A BSA/AML model validation obviously involves compliance personnel, but a key part of the assessment involves direct input from technology staff.  During a BSA/AML model validation, the auditor will likely ask to speak with the IT Director to discuss Information Security controls associated with the BSA\AML model solution and interfacing systems.  Why is that you ask?  Because the IT department has the responsibility for establishing and maintaining controls that ensure the security, integrity and availability of model data.  Specifically, controls relating to both data and user security along with system changes as explained below:     
            • Data Security – Controls designed to prevent the unauthorized and/or inadvertent disclosure, modification or destruction of model data.  The auditor will be looking for evidence that confirms the existence of controls, including, but not limited to, the following: 
              • A detailed network diagram that identifies all systems that interface with the model. 
              • Evidence of secure data transmission between interfacing systems.
              • System configuration(s) depicting enablement of security settings.
              • System/data backup and data retention procedures. 
            •  User Security – Logical access are controls designed to prevent unauthorized access to sensitive data.  User access should be assigned according to “least privilege” based on role and/or job function.  For example, tellers or other non-BSA staff should be restricted from viewing Suspicious Activity Reports (SARs) and customer reporting.   Access permissions should be reviewed on a scheduled basis to ensure appropriateness of user access considering routine staff and job changes. 
            • Change Management – Change controls are designed to prevent unauthorized and/or inappropriate system modifications.  These controls ensure all system changes are properly initiated, approved and implemented.  System changes, including version updates and server hosting changes, should be categorized based on impact and tested accordingly with appropriate stakeholder involvement to minimize system disruptions.  
            In summary, while the BSA/AML model may be considered a specialized solution owned and operated by the compliance department, the controls outlined above are the same as those surrounding other key applications.  For this reason, IT should not feel an enhanced sense of panic when the BSA/AML auditor comes calling! 

              Remote Notary Vendor Suggestions

              Employee at a credit_union ($598MUSA)
              Geez, looks like Remote Notary vendors are slammed with bid requests. 

              Would greatly appreciate feedback on what RN services other CU's are using. For Example:

              1. Ease of negotiations, set up and use
              2. Promises vs Deliverables
              3. Security
              4. Cost
              5, Tech & Customer Support

              Thanks in advance!

                Show Me How your Audit Plan is Risk-based

                Recently, we have fielded a few questions from financial clients on an examiner request: “Show your IT audit risk assessment with details of scope and frequency.”  What the examiner is really asking is “Show me how your audit plan is risk-based.”  The good news is that you are probably doing everything you need to be doing, you may just not know how to answer to the question.  

                In a risk-based audit plan, risk assessments are used to determine audit scope and frequency.  Does your audit plan contain the following elements?

                • A risk assessment process to describe and analyze inherent risk to IT and information security assets.  The risk assessment process should utilize a scoring system that considers relevant risk factors, and to the extent possible, avoids subjectivity.  The risk assessment should be updated at least annually, or more frequently to reflect changes such as new processes, new infrastructure, new public facing services, security incident or breach, mergers & acquisitions, etc.  
                • An audit cycle where the risk assessment is the driving factor for determining the frequency of audits.  In your audit plan, define audit frequency based on risk scoring – for example, areas with an inherent high-risk score are typically audited annually, and moderate-risk issues might be every other year.  Areas with an inherent critical-risk score, such as social engineering awareness, might be audited or tested at least annually, or even more frequently.  As noted above, major changes or other events could trigger out-of-schedule audits or testing, and your plan should note this.
                Wireless network access is a good example of a function or service where the risk assessment process can be used to determine audit scope and frequency.  If an institution implemented a guest wireless network that doesn’t have access to production resources, the risk assessment would likely result in a low inherent risk for this area, and wireless access might not be included in much or any auditing or testing.  What if the production network was wirelessly accessible?  That would arguably result in a high-risk rating, triggering annual testing as defined by your schedule.  

                The extent of audit planning required depends on size and complexity of your institution.  Audit programs may range from “We just audit everything annually,” to the use of detailed enterprise-wide risk management programs at larger institutions where audit scope and frequency is much more granular.  For smaller institutions, an annual IT audit, penetration test, internal and external vulnerability assessments, and social engineering test will likely cover your needs by testing relevant controls on your risk assessment.  

                If you follow the process as described above, you will be able to confidently answer the “Show me how your audit plan is risk-based” question.  As usual, we have example risk-based audit plan verbiage if you need a place to start, attached.