ZeroSolstice

I think the saying is "missing the forest for the trees.[1]"

Referring someone to another food bank or resource is not addressing or owning the immediate problem, which is what the experiment showed. Those organizations failed at their primary objective and instead of re-evaluating why they failed they hid behind process and procedure and how they were being tricked since it wasn't a "real" problem.

There was a proper way to handle this situation as anyone who has worked or called into customer service or tech support where their issue was addressed no matter what the internal structure of the organization was.

[1] https://www.merriam-webster.com/dictionary/miss%20the%20fore...

Correct, which is why .local wouldn't become a TLD or part of a standard for home network reserved domains.

I agree it would be great to get some of the vendor pushed / common domains put into an accepted standard.

In my interaction with IETF standards they are created / implemented in two ways:

  1. They set the forward direction for a new technology before it is wide spread.
  2. They wait for a technology to become popular / accepted and start to set standards from that baseline.

I doubt .lan, .local, .home, etc will either become public or a standard just based on existing devices that default to these domains and documentation or books that might reference them as example domains.

I didn't see a specific RFC that reserved .lan however from the proposed standard RFC 8375 home.arpa is suggested.

https://datatracker.ietf.org/doc/html/rfc8375

Where? Should they drop them at a starbucks out front? Have an employee volunteer their home address? Put them out front at the office? How long should they hold onto the "free" cables that people are going to ask ridiculous questions such as "Do they work? When were they tested?" Are you going to force people to take all the cable or allow random selections? Are you going to waste the cost savings of moving to the cloud to have one of your tech people monitor requests for pickup? What if no one picks them up are you calling the recycler out again to pick up the cables you could have just given them?

Anyone who has posted "free" things online knows it comes a cost, thats the logic part I was referring too. When you work through the scenarios the "logical" conclusion is to give them to the recycler that you already have out at the datacenter for the systems you are decommissioning.

Free pickup? at a secure data center?

Lets use some logic here. The disposal company is taking the cables with them to recycle them for the copper wire. Same with power cables.

This is common compliance nomenclature. The only people paying the high cost to have a full sized piece of equipment destroyed are governments or R&D companies with unique prototypes.

The hard drives are most likely being shredded since that is a common practice and certification feature offered by most disposal companies.

The servers are being "destroyed" because thats how they will be accounted for in inventory and tax purposes to account for full depreciation. The company isn't "selling" the servers to the disposal company so they are marked as "destroyed."

Unless specified in the contract the disposal company will sell the chassis without the drives to a reseller or if they are being paid to dispose of the system, they will separate the components and recycle the metal.

The same goes for the power and network cables, they will go off to a recycler, its how disposal companies off-set their pricing.

I found that the book "Writing to Learn" by William Zinsser was excellent in convening this process. As noted in the book the author advocated for more writing to be included in all subjects.

  <https://goodreads.com/book/show/585474.Writing_to_Learn>

Reading, writing and math have been the constants utilized throughout life and as such have been core subjects carried through educational systems. I'm not quite sure what subjects and topics we would be teaching future generations that didn't include reading, writing, math and science. At the very least writing should be included in more subjects. The hidden feature of including writing in all subjects, as you might have seen in your history endeavor's, is improvements in critical thinking, formulating cohesive arguments and a clearer understanding of topics.

There are greater difficulties that people will have to do in their daily lives than being "forced" to learn how to read, write and do arithmetic. Maybe learning the lesson of overcoming smaller, difficult tasks will allow them to adapt to greater difficulties in the future.

To quote Seneca:

  A gem can not be polished with friction, nor a man perfected without trials.

This quote mostly applies to people who don't want to spend the time learning existing tooling, making improvements and instead create a slightly different wheel but with different problems. It also applies to people trying to apply "google" solutions to a non-google company.

Kubernetes and all tooling in the cloud native computing foundation(CNCF) were created to have people adopt the cloud and build communities that then created jobs roles that facilitated hiring people to maintain cloud presences that then fund cloud providers.

This is the same playbook that Microsoft did at Universities. They would give the entire suite of tools in the MSDN library away then then in roughly (4) years collect when another seat needs to be purchased for a new hire that has only used Microsoft tools for the last (4) years.

The frontpage should directly show the list of papers, like with HN.

I disagree. There are numerous times where I have browsed the comments on a HN post where people haven't read the article and are just responding to the comment thread. The workflow for this seems a bit different in that a person would have already read a paper and wanted to read through existing discussions or respond to discussion. With that, having the search front and center would follow as the next steps for a person who read a paper and wanted to "search" for discussions related to that paper in particular.

HN is more an aimless browsing which is a bit different than researching a specific area or topic.

  > it hasn't turned around in cyber fwiw and it's been growing for probably 2 decades, 1 decade in earnest. Perhaps b/c SWEs are a profit center vs. the security 
  > cost center, there'll be motivations though. IMO the only thing driving sec eng hiring isn't companies realizing career pipelines are messed up, it's regulations 
  > or getting hacked in profit-damaging ways, and there aren't a ton of companies in those buckets

While the hacks are a driver of the cybersecurity field the biggest driver as with all things is insurance companies and cyber coverage. Insurance companies requiring people to be dedicated on keeping up with vulnerabilities, secure default implementations, data restrictions is what is driving the need and companies just want to fill it to keep their coverage or keep their rates lower. Its the typical idea that if you add more software developers or people to a project it gets done faster, when in reality it doesn't work that way. This is why I think we will see a shift back to a more graduated source of cybersecurity professionals. There wasn't a formal path to being a systems administrator or network administrator compared to Computer Science degree -> developer.

Thanks for the astute discussion. Its much better than the "one" line bot responses that you typically see now.

[1] For all the young kids these jobs were renamed DevOPS, NetOPS, SRE, etc. Previously these responsibilities were just part of operating a network.

  > Because the project was big enough to warrant more than one person.

  > I have a whole team surrounding me to handle non-technical/non-development incidentals.

  > Most companies would have had a lot more budgeted and would have pre-hired five devs.

  > Then everything would have moved glacially slow, fulfilling the prophecy that five devs were needed.

I'm not sure I see this as a reality anytime soon.

  > Those folks have a lock bc there’s a small group of who knows assembly and OSs across multiple systems very well and knows if from a security context.

As an example if you get hacked and you make a cyber insurance claim you are going to have to sufficiently explain to the insurance company what happened so they can try to get out of paying you and you won't be able to say "Xyz program says it found malware, just trust what it says." If people don't understand how the result was generated they could be implementing fixes that don't solve the problem because they are depending on the LLM/decision tree to tell them what the problem is. All these models can be gamed just like humans.

I'm not quite sure I agree that a better LLM is what has been keeping people from implementing pipeline logic to produce actionable correlation security alerts. Maybe it does improve but my assumption is much like we still have software developers any automation will just create a new field of support or inquiry that will need people to parse.

You will start to see this turn around as companies realize they need to go back to the path of entry -> mid -> Senior/Principal. For cybersecurity this is operations and/or development -> cybersecurity w/ focus on either dev or operations. Then at the Senior/Principal layer people can float between things. This isn't too far off from many other jobs, no EE out of school is designing circuits and boards from scratch its debug what Senior EE's have created or problems in existing products, then you work your way up. Its the same with cybersecurity does a person that hasn't developed software start out doing reverse engineering? Does a person develop or approve security policies, devices, network architecture or designs if they haven't every deployed an application or service in production? How are you determining if something is an incident or valid alert if you haven't managed a network.

When money was free companies could hire people for very specific tasks and knowledge areas because it wasn't costing them anything to get the money. This is why lay-offs in engineering, while smaller percentages compared to other departments in the company, are for jobs that are specialized where in previous times it might have made sense to get a consultant or contractor.

Why did you think you needed to hire a junior dev before even starting work on the application? I know estimation can be a difficult task but the typical "I'm moving so fast..." type experiences usually mean you didn't or don't understand your tooling or the scope.

Also how were you going to take on a junior dev and a new framework at the same time? Were you expecting them to know the framework?

As the saying goes though the last 20% takes 80% of the time.

Honestly it sounds like it wasn't a tool that is needed often, if it was you or someone else would have already written it. Or you don't regularly day-to-day program enough in javascript / python to do this quickly. There isn't anything wrong with that, as you mentioned, you have entry level security engineers that typically handle those tasks. Creating a tool goes fast when you know exactly what you want it to do and don't have to explain to another person all the requirements and pitfalls to avoid based on experience you might have in writing quick scripts. I don't know if this really changes anything.

80% of being a good security engineer is knowing the big picture, all the parts and how they work. The correlation that LLM produces has no value if its not actionable. You are the one that determines the weights, values, and features that are important. I'd be very curious of how you currently account for scheduled outages, unscheduled outages, new deployments, upgrades of existing systems, spinning instances up and down for testing, laptop device swap-outs, traffic in different silos. How are you baselining normal communications and session timing between services or across protocols? If you are in the cloud is baselining done by service HTTP, DNS, DB, etc? I could see different weights being constructed to represent defense-in-depth but this would seem to be a constant amount of work while also investigating or feeding true/false positives back into the system.

Entry-level cybersecurity isn't a thing which is why it isn't working out as typically you need prior dev, ops, devops, sre, sysadmin, etc existing experience. The talent shortage is because you can't do an undergrad in cybersecurity and somehow pick-up the prior operational knowledge that develops your skills for understanding and troubleshooting how systems, networks, and applications all function together. Cybersecurity as it stands, and you mention, is in my experiences best as a focus off-of computer science. I mean even the CISSP requires working experience in the field.

The one item I think you are overlooking is that you have the experience in how everything works together which makes a tool like ChatGPT or some other analyzer where you can ask the "right" questions a useful tool because you have the mental mapping and models through experience of the questions to ask. So while a security analyst job might go away you are back at the original problem of developing security engineers that know the architecture, flows, daily expectations, etc and having a LLM buddy is not going to turn a security analyst directly into a cybersecurity engineer over night.

Well two things:

1. Maybe you aren't the intended audience for this.

2. They are lecture notes and homework which are typically distilled from a textbook or industry experience topic.

These are helpful items for someone teaching or speaking to these topics, you aren't supposed to directly learn from the notes. Its the equivalent of saying you could learn c++ from a power point presentation.

The lectures aren't a how-to guide. The items that are explained are to provide reference to the lecture material. For example the apache2 setup could just as easily be nginx, lighttpd on Windows, FreeBSD, Redhat, etc. Its explaining the concept of a DDoS, malware, viruses, spam, cryptography. Cloud primitives? how would that relate to computer and network security instead of being covered in an operating systems course? They are just abstractions of physical hardware properties and would be specific to the implementation you were working on, ie AWS, GCP, Azure, etc. Any specific implementation or security is completely dependent on what the vendor implements and is ephemeral.

The OWASP top 10 is self described as an awareness document[1] it wouldn't be something you teach a college course on.

[1] https://owasp.org/Top10/A00_2021_How_to_use_the_OWASP_Top_10...

Says its lecture notes right at the top.

  > "Think of these lecture notes as a living textbook that strives to strike a..."

Can you elaborate on what you would add for the cloud, AD, or vulnerability content?

In my perspective what you listed are simply tools and vendor offerings of which reading the documentation or getting a vendor specific certification is the expected process. This course teaches the foundations on which the items you listed were built from. The reason you probably feel that its so dated is because security hasn't changed we just like to keep calling it different things. Classes like this tend to focus on the more permanent area of network protocols as most exploits just ride on top of existing standards which if you understand those you can understand the "latest" vulnerabilities, cloud infrastructure, IAM and so on.

At what point though is this just consulting? Since everyones risk tolerances are different and may or may not have good network architectures or software practices how would this apply generally to other companies or networks?

I would add the additional problem of CVE's being devoid of any useful information which lead to generic tests being created by vulnerability scanners as they have the same lack of insight as everyone else thats trying to patch the issue. Thus creating higher false positives or wasted effort trying to confirm an exploit yourself. I get not wanting to provide a PoC because "script kiddies" might use them but if we want vulnerabilities patched regularly you have to provide better assurances that they are valid and that we can show they are patched aka tests.

Shouldn't your analysis/understanding show that upgrading the library is enough? If a CVE or vulnerability scanners test isn't telling you the problem that needs to be solved upgrading a library or anything else won't make a difference and you wouldn't know the problem either way.

Approaching vulnerability management from a developers view is a very narrow scope.

What sources do you have to cite on development costs and regular maintenance? Autonomous trucking is an add-on to existing trucks which are already being built regularly. We already perform road maintenance and account for it in local, state, and federal budgets as it services more vehicle's and destinations than just "autonomous trucks."

This is my thinking as well. We need to build for the task at hand not try and integrate into what we already have. The first sentence in this article is where the failed assumptions are.

  "Trucking was supposed to be the ideal first application of autonomous driving. Freeways contain predictable, highly structured 
  driving scenarios.."

Unfortunately we didn't expand upon thinking about multiple intersections and their traffic lights being a network. We have fixed programming of lighting schedules that don't change unless a traffic survey is done. In most cases these are limited in their occurrences which doesn't reflect the dynamics of driving.

As an example I'm sure most people don't mind moving as long as they feel like they are getting somewhere. With the dynamics of traffic you could re-direct people to a different on/off ramp even though its further away to keep the same rate of speed for everyone. Maybe you send people down a different or parallel road for longer because it will get them there at the same time verses stop-and-go traffic because everyone wants to use the same or well-known road.

Stop being moronic. Different transportation mediums exist for a reason. Trains in the US are currently suited for long haul transportation at which they excel at. We already tried running rail lines to warehouses and distribution centers and determined trucks were a better form of last mile transportation.

Do you think that no one at UPS, FedEx, Walmart or Amazon has ever looked at how much more efficient or what cost saving they could get if "only they had a rail line to their warehouses verse a road?"

What the discussion is looking at is making a micro improvement to what we have already tested as the better method of delivery, trucks in this case. Where the issue is coming about is we are trying to build autonomous actions into a hybrid roadway verse dedicating a portion of a roadway to autonomous driving. The article states the following:

  "Trucking was supposed to be the ideal first application of autonomous driving. Freeways contain predictable, highly structured driving 
  scenarios"

Correct this is the best path forward. Night time is typically when there is less traffic and we should be able to at least utilize that for autonomous transportation between distribution centers. Then slowing keep upping the advancement as roads are repaired, replaced, etc. If you build a smart road for lets say just trucking, now you can map out the best places for distribution centers, similar to what UPS, Fedex figured out for air transportation and packages.

Its a bit ridiculous that in 2024 we have all these apps that tell you about accidents and obstructions but none that actually help re-direct traffic in a meaningful way. You have to hedge your bets on any "suggested" better route.

With smart roads department of transportation could get real analyze on crowded intersections, best place for future on/off ramps, access roads, etc. Traffic congestion and planning is usually an after thought when housing developments go up and then its a catch-up game.