Another year has come and gone.
I went back to Shmoocon, and then I went to FETC for the first time. Both interesting in their own way, both informative. Depending on your specific working environment, both are worth a look.
The experience of going from the world of deep security to the world of Educational Technology did drive home the need to better communicate. Specifically, the security world is doing a terrible job of explaining why security basics are important to schools. I heard any number of vendors on the show floor talk about their security tools, and even some workshop sessions talk about what to defend against. None of them talked about what it means to defend a network, what should be taught to teachers AND students, what should be prioritized.... What needs to be done BEFORE you buy the blinky-box or the pen-test service. No one said "learn your network, learn your inventory, close the obvious holes, learn what's normal and look for anomalies."
I am not going to rant (much) on this subject. Instead, I will try (again) to put basic starter activities down on paper (blog) and see if it helps anyone.
Plus a quick review of my favorite Shmoocon and FETC talks.
Stay tuned....
Monday, January 30, 2017
Wednesday, March 30, 2016
1 account to rule them all and in the darkness bind them (SHIPS)
OK, so the quote is not exactly correct.
When dealing with a large network, you will often run into a problem with local admin access to a desktop. Which is to say, normal routine is to disable such accounts (a good idea) and use some sort of network based desktop admin account. That works, so long as the machine is authenticating to the network. What happens when that fails?
In many organizations they set a password for a local admin account that can be computed per-device off of the asset tag. Which is great, but what happens when a team member leaves the IT dept? Do you change the way its computed and then change all those local passwords? What happens if you miss one? How about when you have one person leave per month for three months?
Well, there is an answer. Its not perfect but its pretty damn good. Its SHIPS.
SHIPS stands for Shared Host Integrated Password System which tells you someone really wanted the acronym to spell ships. SHIPS is a system that automatically changes local admin passwords on Mac, Windows and Linux. It keeps track of current and past passwords, changes them regularly, keeps track of who checked them out and allows for full accountability.
Its the free Thycotic for the local admin accounts.
Its a great tool and an excellent addition to the IT Security toolbox.
(the install manual is here)
When dealing with a large network, you will often run into a problem with local admin access to a desktop. Which is to say, normal routine is to disable such accounts (a good idea) and use some sort of network based desktop admin account. That works, so long as the machine is authenticating to the network. What happens when that fails?
In many organizations they set a password for a local admin account that can be computed per-device off of the asset tag. Which is great, but what happens when a team member leaves the IT dept? Do you change the way its computed and then change all those local passwords? What happens if you miss one? How about when you have one person leave per month for three months?
Well, there is an answer. Its not perfect but its pretty damn good. Its SHIPS.
SHIPS stands for Shared Host Integrated Password System which tells you someone really wanted the acronym to spell ships. SHIPS is a system that automatically changes local admin passwords on Mac, Windows and Linux. It keeps track of current and past passwords, changes them regularly, keeps track of who checked them out and allows for full accountability.
Its the free Thycotic for the local admin accounts.
Its a great tool and an excellent addition to the IT Security toolbox.
(the install manual is here)
DNS?
Are you watching your DNS logs?
It is rare for anyone in your environment to look for a domain with more than 20 characters in its name. Actually, most have 8 characters according to this slightly out of date bit of research.
All of which means that if you see a spike in requests for LOONG name lookups, something is wrong.
The only way to tell is to look over your DNS logs, or even better have your log system (Elastic anyone?) alert you when it sees such lookups.
Dave Piscitello goes into it further here, but the basics are to monitor who is making what kinds of calls to your DNS and how often.
It is rare for anyone in your environment to look for a domain with more than 20 characters in its name. Actually, most have 8 characters according to this slightly out of date bit of research.
All of which means that if you see a spike in requests for LOONG name lookups, something is wrong.
The only way to tell is to look over your DNS logs, or even better have your log system (Elastic anyone?) alert you when it sees such lookups.
Dave Piscitello goes into it further here, but the basics are to monitor who is making what kinds of calls to your DNS and how often.
Wednesday, January 20, 2016
More on certifications and the job market
Earlier I commented on a particularly empty article from CSO Online regarding certifications.
This time I am commenting on a different slightly more useful article from the same publication.
Its by the same author and begins to discuss which certifications are useful, although in the lightest of terms. She suggests different certs for Security Ops, Security Analysts and CERT analysts. She does not explain why, or what the difference is, I guess that was beyond scope.
So lets help her fill in the missing information.
Except there is no clear answer as to what the differences are. Depending on source (or employer) they are all the same, or vastly different. Security Wizard has some nice definitions that are similar but no where near exact to the ones on Monster. The upshot being that based on acronyms alone, I don't know what the differences are or why you should focus on cert A instead of B.
I was at Shmoocon this past weekend and had a chance to speak again to the awesome recruiter from tenable who gave an impromptu talk at BSides Las Vegas. A quick chat and a fast review of the way things work, and I came away with the same understanding.
Certifications are not bad, but they won't get you the job on their own. You need to show your knowledge, your interest and your ability to learn. Build a home lab, secure your home network, hack yourself, and find out if you like this work.
Then show that enthusiasm to prospective employers. When they ask for your experience, feel free to wax poetic about firmware hacking on your consumer grade router, or how you set up OIP on your home network just to see what is going on. For a starting position, having that under your belt will be more impressive than putting yourself into debt for your CISSP.
Nothing I am saying is new. IT boils down to: Certification is great, but don't beggar yourself getting them, and dont expect their presence to be more important than your abilities and activities.
Whenever I write a post, I come across related interesting resources that don't make it into the post. I think I will start putting them at the bottom.
Odds and ends resources:
Red Team
"how to become a hacker"
Hacking Tutorial
EvilZone - Where to start with hacking
Hack This Site
Blue Team
Blue Team HandBook
Cyber Guardian:Blue Team
(updated to correct typos)
This time I am commenting on a different slightly more useful article from the same publication.
Beyond the basics: The certifications you need based on the path you choose
Its by the same author and begins to discuss which certifications are useful, although in the lightest of terms. She suggests different certs for Security Ops, Security Analysts and CERT analysts. She does not explain why, or what the difference is, I guess that was beyond scope.
So lets help her fill in the missing information.
Except there is no clear answer as to what the differences are. Depending on source (or employer) they are all the same, or vastly different. Security Wizard has some nice definitions that are similar but no where near exact to the ones on Monster. The upshot being that based on acronyms alone, I don't know what the differences are or why you should focus on cert A instead of B.
I was at Shmoocon this past weekend and had a chance to speak again to the awesome recruiter from tenable who gave an impromptu talk at BSides Las Vegas. A quick chat and a fast review of the way things work, and I came away with the same understanding.
Certifications are not bad, but they won't get you the job on their own. You need to show your knowledge, your interest and your ability to learn. Build a home lab, secure your home network, hack yourself, and find out if you like this work.
Then show that enthusiasm to prospective employers. When they ask for your experience, feel free to wax poetic about firmware hacking on your consumer grade router, or how you set up OIP on your home network just to see what is going on. For a starting position, having that under your belt will be more impressive than putting yourself into debt for your CISSP.
Nothing I am saying is new. IT boils down to: Certification is great, but don't beggar yourself getting them, and dont expect their presence to be more important than your abilities and activities.
Whenever I write a post, I come across related interesting resources that don't make it into the post. I think I will start putting them at the bottom.
Odds and ends resources:
Red Team
"how to become a hacker"
Hacking Tutorial
EvilZone - Where to start with hacking
Hack This Site
Blue Team
Blue Team HandBook
Cyber Guardian:Blue Team
(updated to correct typos)
Wednesday, January 13, 2016
IT Awareness on the cheap
"I run an IT department and I have no real budget for anything the CEO cannot see."
Whatever else that sentence may say about the state of business, it is often true.
Here is a quick list of resources that are free or super cheap that can help you (the IT department) get the situational awareness you need in order to keep things secure. Just remember that Time=Money so while the initial Money cost is low, the Time cost makes up for it.
1) Inventory and Maintenance - Spiceworks. Actually I am less and less happy with Spiceworks because it "requires" admin level access to desktops and servers (and switches) to give really useful data. As such it kind of scares me. However, it is free and useful. Just be very careful with it.... maybe don't leave it on all the time? I have not yet found a comfortable level of use but I'm working on it.
2) SNMP Monitoring - Spiceworks can do this, but I don't like it as stated above. So I have been using Observium. Really powerful, and free for basic use. The paid (more updates and some support) version is ~$200/year. Not going to break the bank with that one. Its also pretty, capable, and as secure as you choose to make it. On a side note, remember to use different SNMP community names for every class of device, make them random and long, disable Version1 (and 2 if you can) and try to use read only whenever possible. Oh, right, and setup Apache to run HttpS. Install guides are on the Observium website and Apache SSL tutorials abound. I used this one for CentOS.
3) Log Collection and Correlation - Make an ELK (ElasticSearch, LogStash and Kibana) stack. This has gotten easier since I first started talking about it. SPLUNK is still the gold (platinum?) standard and it still costs a huge amount to run. What I have been toying with lately is using my deeply limited free splunk install to fine tune my log correlation rules (one server at a time) and then applying what I learn to the ELK stack. You can get a basic idea of what windows logs to keep an eye on by going here or here or here. If your running a VM, you can use the very badly named SexiLog which is an OVF running elastic with tweaks for keeping track of VM logs, but can also handle everything else too. Lastly there is the Nagios version. It has a nice front end, comes with support. It is not free, but is far less expensive than splunk and very robust. Here is a nice little write up on it.
4) IDS/SIEM - The fair warning of Time=Money goes six times over on this one. These things take a lot of attention to get them set up correctly, and even then they need to be tweaked all the time. That being said, AlienVault OSSIM works well enough for most of us. AlienVault USIM is the paid product and is expensive, but has good support.
5) Up-time and Accessibility - Most of us have external servers/services and internal servers with outward facing sites. Monitoring it from inside the network is not the best way to keep tabs on it. I use/like the Monitor.us free monitoring dashboard. Simple pings, uptime, full page loads, etc... From two locations around the world.
With a VMware/HyperV server and these tools, you can get a decent view of your network without spending too much money. If you spend some time at home building these out in your lab (or even a work lab if your lucky enough to have one) you should be able to get it all running together without too much time spent, but as always RTFM.
Good luck.
Whatever else that sentence may say about the state of business, it is often true.
Here is a quick list of resources that are free or super cheap that can help you (the IT department) get the situational awareness you need in order to keep things secure. Just remember that Time=Money so while the initial Money cost is low, the Time cost makes up for it.
1) Inventory and Maintenance - Spiceworks. Actually I am less and less happy with Spiceworks because it "requires" admin level access to desktops and servers (and switches) to give really useful data. As such it kind of scares me. However, it is free and useful. Just be very careful with it.... maybe don't leave it on all the time? I have not yet found a comfortable level of use but I'm working on it.
2) SNMP Monitoring - Spiceworks can do this, but I don't like it as stated above. So I have been using Observium. Really powerful, and free for basic use. The paid (more updates and some support) version is ~$200/year. Not going to break the bank with that one. Its also pretty, capable, and as secure as you choose to make it. On a side note, remember to use different SNMP community names for every class of device, make them random and long, disable Version1 (and 2 if you can) and try to use read only whenever possible. Oh, right, and setup Apache to run HttpS. Install guides are on the Observium website and Apache SSL tutorials abound. I used this one for CentOS.
3) Log Collection and Correlation - Make an ELK (ElasticSearch, LogStash and Kibana) stack. This has gotten easier since I first started talking about it. SPLUNK is still the gold (platinum?) standard and it still costs a huge amount to run. What I have been toying with lately is using my deeply limited free splunk install to fine tune my log correlation rules (one server at a time) and then applying what I learn to the ELK stack. You can get a basic idea of what windows logs to keep an eye on by going here or here or here. If your running a VM, you can use the very badly named SexiLog which is an OVF running elastic with tweaks for keeping track of VM logs, but can also handle everything else too. Lastly there is the Nagios version. It has a nice front end, comes with support. It is not free, but is far less expensive than splunk and very robust. Here is a nice little write up on it.
4) IDS/SIEM - The fair warning of Time=Money goes six times over on this one. These things take a lot of attention to get them set up correctly, and even then they need to be tweaked all the time. That being said, AlienVault OSSIM works well enough for most of us. AlienVault USIM is the paid product and is expensive, but has good support.
5) Up-time and Accessibility - Most of us have external servers/services and internal servers with outward facing sites. Monitoring it from inside the network is not the best way to keep tabs on it. I use/like the Monitor.us free monitoring dashboard. Simple pings, uptime, full page loads, etc... From two locations around the world.
With a VMware/HyperV server and these tools, you can get a decent view of your network without spending too much money. If you spend some time at home building these out in your lab (or even a work lab if your lucky enough to have one) you should be able to get it all running together without too much time spent, but as always RTFM.
Good luck.
Is this really such a surprise
A friend of mine wrote this article:
And I just fail to see why this is new or noteworthy.
Some things that need to be noted.
Mr. Goldfarb is an incredibly intelligent person. He is also an accomplished and experienced security professional. He has years of Security operations experience, experience I do not have. His job is very much one in which he spends his time evangelizing FireEye Products and information security in general.
I think that some of my reaction comes from my background, and that might very well cover his viewpoint as well.
Mr. Goldfarb was never in IT operations. Rather he has spent his career almost exclusively in Security Operations. This is not a bad thing, and he will tell you at length why the two must be separate entities and why having a Sec.Ops. background is important for a CIO/CSO to function properly.
I disagree.
I came up through the IT world, so of course I have an IT Ops centric view of things. At one job the Sec. Ops. team was built form the IT and Network group. It gave Sec. Ops. an insight not only into how our network functioned, but into the human side of things as well. An understanding of who traveled where, which employees were killing the system updates because they worked late and when to expect total security failure due to specific employee activity.
Admittedly this was not at a HUGE company, we had ~200 total employees, 10% of which were in some way directly working with, for or in IT. We did however have about 70% of the company traveling internationally at least once a month, with 5 offices on 3 continents. This was a small but by no means simple environment. The extra insight allowed the Sec. Ops. team to head off major issues, prep for "walking disasters" and ignore normal activity coming from what might seem unusual locations.
I also worked for a contractor that provided the IT Ops, but not the Sec. Ops. for a government organization. The organization had several thousand employees, around 1% were involved in IT, and around the same percentage traveled regularly. The contractor that provided Sec. Ops. had no clue what was going on at the human level and there was constant work interruption because of misinterpreted activity. Either allowing malicious activity to continue unabated, or stopping legitimate activity because it tripped some pre-built signature. The employees and IT Support staff hated working with the Sec. Ops. group because they never seemed to know what was going on, despite being well staffed and very bright.
What I am saying is that employee aware correlation of events is nothing new, and no great surprise for anyone who has ever worked on/with a helpdesk. I have endless stories across multiple employers about strange event X that happened every single time a particular employee used a computer. Always traceable to something they were doing, and occasionally causing widespread issues. Ignoring those connections has never been a workable plan.
If the security world at large has so disconnected from those who use the infrastructure they are securing that Mr. Goldfarb's article is news, then I think its time to look again at the inclusion or exclusion of IT in the current Sec. Ops. mix.
Phishing, spear phishing, user targeting, etc... The list of attack techniques that focus on the employee and not the technology is extensive. It is extensive and the attacks are ubiquitous. Why is it a surprise that Sec. Ops. needs to know what the people who use the technology do in order to keep them and the work environment safe? We are supposed to be ensuring the safety of the business so that the people who work there can do business, whatever that business is. Does ignoring their business activities make sense? Is this idea something that CIOs and CSOs are unaware of?
On the other hand its always possible that Mr. Goldfarb happened to be thinking on this, that it was no great surprise or unusual insight, and he just needed a topic for a post.
In either case, I thank him for giving me a reason to write another post of my own.
On a related note (having to do with correlating your log events) --
Lately I have been spending a lot of time working with an ELK stack.
(if you don't know what it is, its a fantastic tool for correlating log events across servers, services and environments.... Its just not always the easiest thing to get running smoothly. You can find more on it here: https://www.elastic.co/ and if your either outsourcing your log collection or don't have any, its a great thing to invest some time into. It now goes into my list of things any IT dept should have.)
I am not yet fluent in its use, however it strikes me as trivial to use it in a manner that will correlate user login events with activities that raise eyebrows. Or even just timing. This might be the first step in allowing you to see who is doing what, when and even possibly where in an SMB environment.
The User's Point of View
And I just fail to see why this is new or noteworthy.
Some things that need to be noted.
Mr. Goldfarb is an incredibly intelligent person. He is also an accomplished and experienced security professional. He has years of Security operations experience, experience I do not have. His job is very much one in which he spends his time evangelizing FireEye Products and information security in general.
I think that some of my reaction comes from my background, and that might very well cover his viewpoint as well.
Mr. Goldfarb was never in IT operations. Rather he has spent his career almost exclusively in Security Operations. This is not a bad thing, and he will tell you at length why the two must be separate entities and why having a Sec.Ops. background is important for a CIO/CSO to function properly.
I disagree.
I came up through the IT world, so of course I have an IT Ops centric view of things. At one job the Sec. Ops. team was built form the IT and Network group. It gave Sec. Ops. an insight not only into how our network functioned, but into the human side of things as well. An understanding of who traveled where, which employees were killing the system updates because they worked late and when to expect total security failure due to specific employee activity.
Admittedly this was not at a HUGE company, we had ~200 total employees, 10% of which were in some way directly working with, for or in IT. We did however have about 70% of the company traveling internationally at least once a month, with 5 offices on 3 continents. This was a small but by no means simple environment. The extra insight allowed the Sec. Ops. team to head off major issues, prep for "walking disasters" and ignore normal activity coming from what might seem unusual locations.
I also worked for a contractor that provided the IT Ops, but not the Sec. Ops. for a government organization. The organization had several thousand employees, around 1% were involved in IT, and around the same percentage traveled regularly. The contractor that provided Sec. Ops. had no clue what was going on at the human level and there was constant work interruption because of misinterpreted activity. Either allowing malicious activity to continue unabated, or stopping legitimate activity because it tripped some pre-built signature. The employees and IT Support staff hated working with the Sec. Ops. group because they never seemed to know what was going on, despite being well staffed and very bright.
What I am saying is that employee aware correlation of events is nothing new, and no great surprise for anyone who has ever worked on/with a helpdesk. I have endless stories across multiple employers about strange event X that happened every single time a particular employee used a computer. Always traceable to something they were doing, and occasionally causing widespread issues. Ignoring those connections has never been a workable plan.
If the security world at large has so disconnected from those who use the infrastructure they are securing that Mr. Goldfarb's article is news, then I think its time to look again at the inclusion or exclusion of IT in the current Sec. Ops. mix.
Phishing, spear phishing, user targeting, etc... The list of attack techniques that focus on the employee and not the technology is extensive. It is extensive and the attacks are ubiquitous. Why is it a surprise that Sec. Ops. needs to know what the people who use the technology do in order to keep them and the work environment safe? We are supposed to be ensuring the safety of the business so that the people who work there can do business, whatever that business is. Does ignoring their business activities make sense? Is this idea something that CIOs and CSOs are unaware of?
On the other hand its always possible that Mr. Goldfarb happened to be thinking on this, that it was no great surprise or unusual insight, and he just needed a topic for a post.
In either case, I thank him for giving me a reason to write another post of my own.
On a related note (having to do with correlating your log events) --
Lately I have been spending a lot of time working with an ELK stack.
(if you don't know what it is, its a fantastic tool for correlating log events across servers, services and environments.... Its just not always the easiest thing to get running smoothly. You can find more on it here: https://www.elastic.co/ and if your either outsourcing your log collection or don't have any, its a great thing to invest some time into. It now goes into my list of things any IT dept should have.)
I am not yet fluent in its use, however it strikes me as trivial to use it in a manner that will correlate user login events with activities that raise eyebrows. Or even just timing. This might be the first step in allowing you to see who is doing what, when and even possibly where in an SMB environment.
A useless teaser article, and my own near useless advice.
This article so annoyed me that I had to mention it.
I keep an eye on the latest version of the "how to break into security" article. They often have some good suggestions, and I like to see how it has changed over time.
However, this one counts as a waste of time and bandwidth. The first thing I noted was that the style is wordy yet vapid. Taking a LONG time to say simple things and not saying much at all. Here is my recap:
[The author] started as a teacher, then got tired of it, went back to school for an MFA, did not expect to become a journalist, has been in the security journalism field for a year, discovered things change fast and everyone is looking to hire.
All actually useful information is promised in the next installment.
The title of this amazing Opus?
With a title like that I expected more than a promise of information later. No where in this "article did the author give us solid reasons for certification, a list of certs, a suggestion of what certs matter to which groups....nothing.
Thank you CSO Online magazine for bringing us the amazing article.
I can only hope that when the series is done, the aggregate is useful.
So waht should you do if you want to start in the security field by getting a certification or two?
First, have a plan. Second, don't spend money you don't have. I know a number of people who got themselves into trouble spending thousands on certifications dreaming of a high paying job without actually having a plan that went beyond getting the cert.
This past August I went to the BSides Las Vegas conference. They managed to wrangle a Q/A session with a bunch of head hunters representing some big name companies in the security sector. The question of Certs came up early and was quickly dismissed. Its not that certs don't count, its that they are a single data point, and not even the most important.
The most important thing they wanted to know was "what are you doing in your lab?" Which really means, what are you teaching yourself at home? Have you taken the time to test yourself on a few VMs running on your laptop? Have you secured your own network? Your own life? Can you speak intelligently about security? Those discussions, more than the letters after your name, were the most important and telling item looked for during an interview.
As for those who DO like certification, that group was made of consulting and contracting firms. Their contracts often require certs for the people they put in place, but those certs change regularly and given the right person the company will pay for the test and sometimes even the training.
So what does this all mean for you? It means get some informal training on sites like Cybrary and HackerAcademy or even Coursera. This wont give you any certs, but it will give you a foundation. Then get some VMs up and running, re-purpose those old PCs, grab dying machines from friends/neighbors/the municipal dump and build a lab[here and here and here].
Lastly, get excited and go learn. If you find yourself up til 2am working on a thorny tech issue with your security lab, your doing it right.
I have been criticised in the past for this view, so I will explain it now and you should understand that it is an opinion, not a set of facts.
You do not have to love Security or IT or Fixing things to go into it, but you will be a far better practitioner if you do. The best indicator of success is the ability to persevere. Its far easier to persevere when you like what your working on. So yes, you can take a bunch of certs, pass them all, and have the technical knowledge to be a security professional without a home lab. However the person with the home lab who struggles to understand and to practice will be a far better hire.
This advice is free, take it for what its worth.
I keep an eye on the latest version of the "how to break into security" article. They often have some good suggestions, and I like to see how it has changed over time.
However, this one counts as a waste of time and bandwidth. The first thing I noted was that the style is wordy yet vapid. Taking a LONG time to say simple things and not saying much at all. Here is my recap:
[The author] started as a teacher, then got tired of it, went back to school for an MFA, did not expect to become a journalist, has been in the security journalism field for a year, discovered things change fast and everyone is looking to hire.
All actually useful information is promised in the next installment.
The title of this amazing Opus?
Why certificates matter, and which ones matter most
With a title like that I expected more than a promise of information later. No where in this "article did the author give us solid reasons for certification, a list of certs, a suggestion of what certs matter to which groups....nothing.
Thank you CSO Online magazine for bringing us the amazing article.
I can only hope that when the series is done, the aggregate is useful.
So waht should you do if you want to start in the security field by getting a certification or two?
First, have a plan. Second, don't spend money you don't have. I know a number of people who got themselves into trouble spending thousands on certifications dreaming of a high paying job without actually having a plan that went beyond getting the cert.
This past August I went to the BSides Las Vegas conference. They managed to wrangle a Q/A session with a bunch of head hunters representing some big name companies in the security sector. The question of Certs came up early and was quickly dismissed. Its not that certs don't count, its that they are a single data point, and not even the most important.
The most important thing they wanted to know was "what are you doing in your lab?" Which really means, what are you teaching yourself at home? Have you taken the time to test yourself on a few VMs running on your laptop? Have you secured your own network? Your own life? Can you speak intelligently about security? Those discussions, more than the letters after your name, were the most important and telling item looked for during an interview.
As for those who DO like certification, that group was made of consulting and contracting firms. Their contracts often require certs for the people they put in place, but those certs change regularly and given the right person the company will pay for the test and sometimes even the training.
So what does this all mean for you? It means get some informal training on sites like Cybrary and HackerAcademy or even Coursera. This wont give you any certs, but it will give you a foundation. Then get some VMs up and running, re-purpose those old PCs, grab dying machines from friends/neighbors/the municipal dump and build a lab[here and here and here].
Lastly, get excited and go learn. If you find yourself up til 2am working on a thorny tech issue with your security lab, your doing it right.
I have been criticised in the past for this view, so I will explain it now and you should understand that it is an opinion, not a set of facts.
You do not have to love Security or IT or Fixing things to go into it, but you will be a far better practitioner if you do. The best indicator of success is the ability to persevere. Its far easier to persevere when you like what your working on. So yes, you can take a bunch of certs, pass them all, and have the technical knowledge to be a security professional without a home lab. However the person with the home lab who struggles to understand and to practice will be a far better hire.
This advice is free, take it for what its worth.
Subscribe to:
Comments (Atom)