DiscoverPwned: The Information Security Podcast
Pwned: The Information Security Podcast
Claim Ownership

Pwned: The Information Security Podcast

Author: Justin Fimlaid

Subscribed: 21Played: 105


Pwned is a weekly information security podcast addressing real-world cybersecurity and information security challenges. Each week we cover a new topic from cybersecurity, to information security, to best practices, to security technology, and how-to's. All topics are from Security professionals, and CISOs and security stories from the field.
30 Episodes
As Facts Change So Does My Opinion
Sponsor: https://www.nuharborsecurity.comContact Me: @justinfimlaidLinkedIn: opinion ofsecurity 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 havesenior industry and junior skill set.  Our collectiveindustry is not helping us be better. Security product companies are coming to the market with new halfsolutions and big marketing budgets. Advisory companies are coming to the table with new buzzwords and hollowconcepts.  And "thoughtleaders" and "trusted advisors" are still trying to figure thisout, and probably not giving the best advice yet.  All these things take our collective eye offthe ball, cause us to loose focus, and distract us from doing well at securityfundamentals.For those listeningto this unfamiliar with our space, here's some examples what we're dealingwith: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 someexamples, but it's not all bad.  We needstay focused though. In order for our security industry to get better we needget back to basics of good security hygiene. I admit this is easier said than done, its going to take time to getthere.  Until we do this we can’t startto 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'tbelieve it do some research in European Election Security…they use goodold-fashion asymmetric encryption.  Ifyou're getting started, or need a realignment go back the fundamentals, goodpolicy, good security architecture, good security hygiene of accounts,etc.  When you've done this, thenhopefully you have a good handle on requirements for security technology andyou have the expertise on how the technology should work in your environment.
The Open Banking Directive and Application Security
Show Notes: https://www.nuharborsecurity.comContact Me: @justinfimlaidLinkedIn: 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:APIKeys can reduce the impact of denial of service attacks. However, when theirissue to third-party clients, they are easy to compromise.  There are a couple things you can do tomitigate security risks including require API keys for every request to theprotected endpoint. You can also returning a 429 message "too manyrequests" if the volume of requests are to high. Do not rely solely on APIkeys to protect high-value resources.7. Validate Content Types:Arest request a response body should match the intended content type in theheader. Otherwise this can cause misinterpretation at the consumer/producerside lead to code injection/execution. Some additional things to think about:Validate Request Content TypesSend Safe Response Content Types8. 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...
The Cavalry is NOT Coming
Show Notes: https://www.nuharborsecurity.comContact Me: @justinfimlaidLinkedIn: hear it all thetime, security burn out is high. I wasn’t until this week that I realized thatfolks got the reason for burn out completely wrong.  After listening to someone tell me that alarge tech company burns out their staff due to work volume and rotates thestaff every 2 years I realized we have it twisted.  I don’t know about you, but most securityfolks I know love doing security and a 60 hour week hasn’t burnt anyone outwhen they do what they love.  If a 60hour week does burn you out, then I'd recommend changing your work professionas a matter of mental health.  Go dosomething you love to do, then no one would have to pay you to work becauseyou'd do for free because you love it.As a former CISO Ican say first hand that the work never burnt me out.  The environment and people are what burned meout.  What I mean by that is that havingaccountability for security and no direct responsibility for security in a $6Borganization was incredibly stressful. Most security folks I know are in thisspot. They have accountability for enterprise security but the role and actionof security is distributed across the organization.  Also - there shouldbe some segregation of duties between IT and Security.   Since security is often monitoring anenvironment they often see mistakes make by peers in the company outside ofsecurity.  Those mistakes can make  security challenging, but those same peersoften have little motivation to clean up those mistakes unless it directlyimpacts their job.  So, security havingto feel like they are in the position of digital janitor and clean up can beexhausting.  There's only so many timesyou'll clean up the spilled milk before you just leave it spilled.Security leadershiphas become a political position, evangelizing for security, educating you workcolleagues on security all so those same company peers when faced with asecurity decision will self-select the correct decision related to securitywhen no one is looking.To amplify matters,you don’t have all the budget you need or want to do your job. Nor likely doyou have all the actual authority to make that decision you want to.  The threat landscape is also shifting sotomorrow is always a new type of cyber attack.All this is to saythat it's a tough job.  Not because ofwork load only, but the surrounding intangibles of working in organizations whoprobably 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 youlistening to this maybe not grasping the challenge, let me propose ananalogy.  We’ve all been out to dinner ata 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 forpreparing it or delivering it.  The chefhas a partial budget, and needs to convince other kitchen staff to pool theirbudget to buy the food needed to serve the menu.  The kitchen staff, however, also have otherdepartment chefs they work for that diverts their attention.  To make matters more complicated, the kitchenis 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, presentationof the food, and delivery of the food.Now, if you went toa restaurant and knew your chef had limited budget, they chef was not directlyresponsible for the kitchen staff, the kitchen staff also served otherdepartment chefs (so they have limited attention to your meal), the chef had nosay on how your food was plated or served, and the kitchen was occasionallyraided by rats, how good do you think your meal would be?

The Cavalry is NOT Coming


Not Invented Here Bias for Security
Show Notes: https://www.nuharborsecurity.comContact Me: @justinfimlaidLinkedIn: ever had an idea to advance your company or another companies securityposture?  And it's a really goodidea.  Like really good.  You do you your homework and dot the"I's" and cross the "T's" and your propose a superiorsolution that sets your organization up for, what you think, is long termsuccess?  When you propose your idea,someone passionately proposes an alternative weaker solution.  Or worse, people take shots at your ideatrying to make it look like swiss cheese for the apparent purpose of making analternate idea better?Ifyes, you might have seen and experienced the "Not Invented HereSyndrome".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 isfrequently used in the context of software development, where a programmer willoverlook all the attributes of an existing solution simplybecause it wasn't produced in-house."Another variantto NIHS is the micro variation comes when the security department or CISO isaccountable for security but doesn't have responsibility for security.  So if you are security professionalrecommending products/solutions that are always "shot down" by thosewith budget authority there could be a few reasons and Not Invented Here mightbe the cause.  NIHS can take a coupleforms (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'salways the counter argument that the Security team always makes sub-tierrecommendations and IT rather keeps the proverbial security train on thetracks.Anyway,NIHS is a real thing and can really be barrier to completing an annualplan.  For organizations that don'tfoster innovation NIHS can really be present in the way the company operatesday to day.  There's some great articleson Not Invented Here and how some of the worlds longest standing companiesfoster innovation and work with external ideas to make their business grow.Some interesting links you might check out...
Download from Google Play
Download from App Store