Episódios
-
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/ -
Estão a faltar episódios?
-
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://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. - Mostrar mais
