Episodes

  • Sponsor: https://www.nuharborsecurity.com

    Contact Me: https://justinfimlaid.com/contact-me/

    Twitter: @justinfimlaid

    LinkedIn: https://www.linkedin.com/in/jfimlaid/

    All the notes: https://www.nuharborsecurity.com/exim-server-vulnerabilities/

    Interesting Tid-bits:



    Known C&C: http://173[.]212.214.137/s

    Firewall Addresses:

    https://an7kmd2wp4xo7hpr.tor2web.su
    https://an7kmd2wp4xo7hpr.tor2web.io
    https://an7kmd2wp4xo7hpr.onion.sh

  • Sponsor: https://www.nuharborsecurity.com

    Contact Me: https://justinfimlaid.com/contact-me/

    Twitter: @justinfimlaid

    LinkedIn: https://www.linkedin.com/in/jfimlaid/

  • Missing episodes?

    Click here to refresh the feed.

  • Sponsor: https://www.nuharborsecurity.com

    Contact Me: https://justinfimlaid.com/contact-me/

    Twitter: @justinfimlaid

    LinkedIn: https://www.linkedin.com/in/jfimlaid/

  • Sponsor: https://www.nuharborsecurity.com

    Contact Me: https://justinfimlaid.com/contact-me/

    Twitter: @justinfimlaid

    LinkedIn: https://www.linkedin.com/in/jfimlaid/

    IOCs: APT10/Operation Cloud Hopper - Indicators of Compromise v3.csv

     

  • Important Links:

    More Info: https://www.nuharborsecurity.com/4-things-to-know-about-the-ohio-data-protection-act/

    State of Ohio Data Protection Act Law Text: https://www.legislature.ohio.gov/legislation/legislation-documents?id=GA132-SB-220

    IAPP Analysis (by Katelyn Burgess): https://iapp.org/news/a/analysis-ohios-data-protection-act/

    What is the Ohio Data Protection Law (by Jenna Kersten): https://kirkpatrickprice.com/blog/what-is-the-ohio-data-protection-act/

    Sponsor: https://www.nuharborsecurity.com

    Contact Me: https://justinfimlaid.com/contact-me/

    Twitter: @justinfimlaid

    LinkedIn: https://www.linkedin.com/in/jfimlaid/

  • Important Links:



    SHA-1 Collision Explanation Page: https://shattered.io/
    Malicious Hashing: Eve’s Variant of SHA-1 https://link.springer.com/content/pdf/10.1007%2F978-3-319-13051-4_1.pdf
    Finding SHA-1 Characteristics: General Results and Applications: https://link.springer.com/chapter/10.1007%2F11935230_1





    Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/

  • Show Notes: https://www.nuharborsecurity.com/building-a-vulnerability-management-program-with-the-end-in-mind/



    Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/

  • Show Notes: https://justinfimlaid.com/quickstart-building-a-security-program-with-the-nist-cybersecurity-framework/h



    Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/

  • Show Notes: https://www.nuharborsecurity.com/red-teaming-vs-penetration-testing/



    Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/

  • Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/



    My opinion of
    security has changed. We are not keeping up. 
    Companies keep getting breached.



    First things first,
    the idea and concepts of security have been around for a while.  In the most general terms, truth is we have
    senior industry and junior skill set. 



    Our collective
    industry is not helping us be better. 
    Security product companies are coming to the market with new half
    solutions and big marketing budgets. 
    Advisory companies are coming to the table with new buzzwords and hollow
    concepts.  And "thought
    leaders" and "trusted advisors" are still trying to figure this
    out, and probably not giving the best advice yet.  All these things take our collective eye off
    the ball, cause us to loose focus, and distract us from doing well at security
    fundamentals.



    For those listening
    to this unfamiliar with our space, here's some examples what we're dealing
    with:



    People failing to understand that IT Operations and security are completely different disciplines.  It's like building a house, you need someone to lay out the blueprint, someone to pour the foundation, someone frame house, someone to do the electricity, someone to the plumbing.  These are not the same people.  IT Operations and IT Security professionals are not the same people.  If you want your house built to code like you want good security hygiene you should hire a security professional.Accounting firms pretending internal controls translates to good security operations.  This is a problem.  Internal control is destination, but you need a map and relevant mechanism of transport to get to you destination.  While I'm sure there are some accountants who play in security, articulating the map and which vehicle to use can be a problem and due to CPA independence rules they are sometimes prohibited from providing tactical guidance.Value added resellers (VAR's) being incentivized to push one product over another. I'm pretty sure I'm going to get some hate mail from this, but I don't think anyone would disagree that vendors and resellers push products to maximize their fiscal standing versus seeking best of breed when it might not be the companies best interest.  This creates a ton of confusion in security and really muddies the water, when this happens the only objective measure is price…which is always a bad space to be.



    Those are some
    examples, but it's not all bad.  We need
    stay focused though. In order for our security industry to get better we need
    get back to basics of good security hygiene. 
    I admit this is easier said than done, its going to take time to get
    there.  Until we do this we can’t start
    to think about automation because if you do crappy security and automate it,
    security automation will allow you just do crappy security faster.  You don't need blockchain, if you don't
    believe it do some research in European Election Security…they use good
    old-fashion asymmetric encryption.  If
    you're getting started, or need a realignment go back the fundamentals, good
    policy, good security architecture, good security hygiene of accounts,
    etc.  When you've done this, then
    hopefully you have a good handle on requirements for security technology and
    you have the expertise on how the technology should work in your environment.

  • Show Notes: https://www.nuharborsecurity.com/open-banking-directive-and-securing-web-application-vulnerabilities/



    Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/



    Application Security Checklist for Web Applications and API's. Also @ NuHarbor Security.



    I have not seen an Open Banking Web Application Checklist, so hopefully this is a good starting point for some.



    1.Ensure HTTPS:



    This one is pretty simple but HTTPS protects authentication credentials in transit for example passwords, API keys, or JSON Web Tokens. It also allows clients to authenticate the service and guarantees integrity of the transmitted data.



    2. Security Tokens: 



    There seems to be a convergence toward using JSON web tokens as the format for security tokens. JSON web tokens are JSON data structure containing a set of claims that can be used for access control decisions. If you are looking for more on JSON formats, here's a good starting point.



    3. Access Control:



    Non-public rest services must perform access control at each API endpoint. Web services in monolithic applications implement this by means of user authentication, authorization of logic in session management.  To this right at scale, user authentication should be through a centralized Identity Provider which issues their own tokens.



    4. Input Validation:



    Anyone developing for a while knows this is a requirement.  If you don't sanitize inputs your application days are numbered.  Contact me if you want the full-list on this one.



    5. Restrict HTTP Methods:



    Apply a whitelist of permitted HTTP Methods (e.g. GET, POST, PUT) and make sure the caller is authorized to use the incoming HTTP method on the resource collection, action, and record.  Leverage 405's when rejecting all requests not matching the whitelist.



    6. API Keys:



    API
    Keys can reduce the impact of denial of service attacks. However, when their
    issue to third-party clients, they are easy to compromise.  There are a couple things you can do to
    mitigate security risks including require API keys for every request to the
    protected endpoint. You can also returning a 429 message "too many
    requests" if the volume of requests are to high. Do not rely solely on API
    keys to protect high-value resources.



    7. Validate Content Types:



    A
    rest request a response body should match the intended content type in the
    header. Otherwise this can cause misinterpretation at the consumer/producer
    side lead to code injection/execution. 
    Some additional things to think about:



    Validate Request Content TypesSend Safe Response Content Types



    8. Manage Endpoints:



    There is a couple things you can do to securely manage your end points. Avoid exposing your management and points by way of the Internet. If your management and points must be accessible to the Internet, make sure that all users authenticate using strong authentication mechanisms such as multi factor authentication. Security by obscurity is not always a good strategy, but exposing management endpoints by way of different HTTP ports or host on different/restricted subnets can also reduce some risk.  Lastly restrict access to these endpoints by firewall ACL's.



    9. Error Handling:



    Keep error message is generic in nature. Try to avoid revealing details of any and all failures when necessary. This will help prevent giving the potential attackers the information they need to game the system or perform a secondary attack with the new information.



    10. Security Headers:



    This one is sometimes overlooked, but to make sure the content of the given resources is interpreted correctly by the browser, the server should always send the "content-type" header with the correct content type, and preferably the "content-type" header should include a charset.  The server should sent the "X-Content-Type-Options: nosniff" security he...

  • Show Notes: https://www.nuharborsecurity.com/how-does-estonias-e-voting-work/



    Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/

  • Show Notes: https://www.nuharborsecurity.com/building-on-people-process-and-technology/



    Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/

  • Show Notes: https://www.nuharborsecurity.com/pci-data-security-standard-4-0/



    Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/

  • Show Notes: https://www.nuharborsecurity.com/10-application-security-authentication-requirements/



    Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/

  • Show Notes: https://justinfimlaid.com/the-cavalry-is-not-coming



    Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/



    I hear it all the
    time, security burn out is high. I wasn’t until this week that I realized that
    folks got the reason for burn out completely wrong.  After listening to someone tell me that a
    large tech company burns out their staff due to work volume and rotates the
    staff every 2 years I realized we have it twisted.  I don’t know about you, but most security
    folks I know love doing security and a 60 hour week hasn’t burnt anyone out
    when they do what they love.  If a 60
    hour week does burn you out, then I'd recommend changing your work profession
    as a matter of mental health.  Go do
    something you love to do, then no one would have to pay you to work because
    you'd do for free because you love it.



    As a former CISO I
    can say first hand that the work never burnt me out.  The environment and people are what burned me
    out.  What I mean by that is that having
    accountability for security and no direct responsibility for security in a $6B
    organization was incredibly stressful. Most security folks I know are in this
    spot. They have accountability for enterprise security but the role and action
    of security is distributed across the organization. 



    Also - there should
    be some segregation of duties between IT and Security.   Since security is often monitoring an
    environment they often see mistakes make by peers in the company outside of
    security.  Those mistakes can make  security challenging, but those same peers
    often have little motivation to clean up those mistakes unless it directly
    impacts their job.  So, security having
    to feel like they are in the position of digital janitor and clean up can be
    exhausting.  There's only so many times
    you'll clean up the spilled milk before you just leave it spilled.



    Security leadership
    has become a political position, evangelizing for security, educating you work
    colleagues on security all so those same company peers when faced with a
    security decision will self-select the correct decision related to security
    when no one is looking.



    To amplify matters,
    you don’t have all the budget you need or want to do your job. Nor likely do
    you have all the actual authority to make that decision you want to.  The threat landscape is also shifting so
    tomorrow is always a new type of cyber attack.



    All this is to say
    that it's a tough job.  Not because of
    work load only, but the surrounding intangibles of working in organizations who
    probably are excited to pass off security can be draining.



    I've got news for you, the Cavalry is NOT Coming.  You are on your own.



    For those of you
    listening to this maybe not grasping the challenge, let me propose an
    analogy.  We’ve all been out to dinner at
    a restaurant. Let’s say being a CISO is like being the chef of the restaurant.
    In this analogy the chef is accountable for your meal, but not responsible for
    preparing it or delivering it.  The chef
    has a partial budget, and needs to convince other kitchen staff to pool their
    budget to buy the food needed to serve the menu.  The kitchen staff, however, also have other
    department chefs they work for that diverts their attention.  To make matters more complicated, the kitchen
    is consistently invaded by rodents and kitchen hygiene is hard to keep up with.
    Our chef also has limited say as to the quality of food prepared, presentation
    of the food, and delivery of the food.



    Now, if you went to
    a restaurant and knew your chef had limited budget, they chef was not directly
    responsible for the kitchen staff, the kitchen staff also served other
    department chefs (so they have limited attention to your meal), the chef had no
    say on how your food was plated or served, and the kitchen was occasionally
    raided by rats, how good do you think your meal would be?

  • Show Notes: https://justinfimlaid.com/soc2-report-quickstart/



    Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/



    Looking for information on SOC2, read more here: https://www.nuharborsecurity.com/do-i-need-a-soc2-report/

  • Show Notes: https://justinfimlaid.com/not-invented-here-syndrome-for-security



    Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/



    Have
    you ever had an idea to advance your company or another companies security
    posture?  And it's a really good
    idea.  Like really good.  You do you your homework and dot the
    "I's" and cross the "T's" and your propose a superior
    solution that sets your organization up for, what you think, is long term
    success?  When you propose your idea,
    someone passionately proposes an alternative weaker solution.  Or worse, people take shots at your idea
    trying to make it look like swiss cheese for the apparent purpose of making an
    alternate idea better?



    If
    yes, you might have seen and experienced the "Not Invented Here
    Syndrome".



    One of the more concise definitions of Not Invented Here Syndrome (NIHS) I've heard come from Techopedia:



    "Not invented here syndrome is a mindset or corporate culture that favors internally-developed products over externally-developed products, even when the external solution is superior.



    NIHS is
    frequently used in the context of software development, where a programmer will
    overlook all the attributes of an existing solution simply
    because it wasn't produced in-house."



    Another variant
    to NIHS is the micro variation comes when the security department or CISO is
    accountable for security but doesn't have responsibility for security.  So if you are security professional
    recommending products/solutions that are always "shot down" by those
    with budget authority there could be a few reasons and Not Invented Here might
    be the cause.  NIHS can take a couple
    forms (this list adapted from Techopedia):



    The other teams don't value the work of others.  They have pride in a negative way.They don't understand or unwilling to try to understand the benefits and lack confidence.Fear that their previous ideas aren't valued.Territorial battles, e.g. internal "turf wars".Fear of having to learn something new.Wanting to control the process.  Would rather "reinvent the wheel" to maintain control.Jealousy that they didn't think of the idea first.Belief that they can do a better job.The other teams don't value the work of others and believe they can do better.  They have pride in a positive way.



    There's
    always the counter argument that the Security team always makes sub-tier
    recommendations and IT rather keeps the proverbial security train on the
    tracks.



    Anyway,
    NIHS is a real thing and can really be barrier to completing an annual
    plan.  For organizations that don't
    foster innovation NIHS can really be present in the way the company operates
    day to day.  There's some great articles
    on Not Invented Here and how some of the worlds longest standing companies
    foster innovation and work with external ideas to make their business grow.



    Some interesting links you might check out...



    https://hbswk.hbs.edu/item/the-benefits-of-not-invented-here



    https://www.forbes.com/sites/haroldsirkin/2017/03/09/not-invented-here-not-at-the-most-innovative-companies/#1d85172c1e35

  • Show Notes: https://www.nuharborsecurity.com/red-teaming-vs-penetration-testing/



    Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/

  • Show Notes: https://justinfimlaid.com/without-wax:-the-quest-for-perfection/



    Sponsor: https://www.nuharborsecurity.com



    Contact Me: https://justinfimlaid.com/contact-me/



    Twitter: @justinfimlaid



    LinkedIn: https://www.linkedin.com/in/jfimlaid/



    I had an English
    Teacher in  High School that was big on
    Etymology.  If you aren't familiar with
    Etymology, its history of how certain words came to be. What I like about
    Etymology is the stories behind certain words. 
    This teacher was one the few teachers I actually liked in High School,
    and I hated English classes so I guess that says a lot.  One word, and one his lessons has always
    stuck with me.  That word in
    Sincere.  Sincere is from the Latin words
    Sin Cera.  In Latin Sin is “without” and
    Cera is “wax”.



    The story of Sin
    Cera dates back to ancient Roman times. 
    The artistry from that time period was seen in statues and ornate marble
    pillars.  What was significant about that
    time period is that artists were appreciated for their perfection.  An apprentice could work for most of their
    life in a specific craft, trade, or artistry…they’d only do that one
    thing.  An apprentice might spend years
    learning how to pick the right type of marble, or they'd spend years learning
    how to carve a specific type of statue, or spend years learning how to polish a
    statue.  The best artists were PERFECT.



    Whats interesting
    about the best artists from Roman Times and the ones that sculpted Marble is
    that they embodied perfection in their craft. 
    They would carve perfect sculptures or perfect marble pillars. 



    For All the other
    artists trying to make a name for themselves, who cut corners in their trade
    and lacked experience used wax to cover their mistakes.  They would use wax to fill holes, cracks and
    mistakes.  The nice thing about wax is it
    could be smoothed and polished to look like marble.  It could be plastered over and it could be
    painted over.  For most buyers they could
    not determine which was artificial Sin Cera or with out wax.  And in some cases they’d never know until the
    artist was long gone. 



    Today when we say we
    are Sincere, it generally means we’re honest. 
    But origins of Sincere also means you are without wax and perfect in
    your craft.



    The reason I bring
    this up, it seems to be relevant as of late. 
    I see more folks and companies trying to capitalize on the Security
    market.  I understand the push, it’s
    capitalism in full-swing.  However, I see
    folks working in the security space who are really confused and are granted
    trust because of a title, position, or certification.  If you are in Security as a buyer or
    supplier, whether inside your own company or a third party…and you claim to do
    security, you need to actually do it. 
    Let me clarify what I mean by that.



    What I mean by that
    is you have an obligation to continuously learn because the threat landscape is
    constantly shifting. 



    I realize every
    subject matter expert started with 0 experience.  But what makes someone sincere in their craft
    isn’t the fact they have a job in the field, it’s the fact they’re a student of
    the craft and continually strive to be perfect. 
    This means always learning and helping others bridge the security
    knowledge gap. This means you can’t just dabble in security, it’s not a bullet
    item on a website or on a resume.  We can
    do this, but we all have to put in the work and make everyone better.



    We have an
    obligation to get this right, if not for us then for the future generation so
    they have a solid foundation to make things better.