Well, to start with, even though this is a tv system, it's a linux computer, so you have all the normal things that happen on a linux computer, ssh access, web server logs, etc.
you can look around and find all sort of suggestions for things to monitor in these logs, but in practice, the best thing to do is to just look at the logs over a few days, find the common things that are logged, configure SEC (or your syslog daemon) to through them away, and report on what remains. At some point during this process, you will see some logs that you say "I want to know about that" so you alert on them instead of throwing them away or letting them just fall through to a daily report. In addition, you have the logs from whatever your television software is. It probably logs things that you will find interesting (like if it's underrunning a buffer). but I don't know what you would care enough about of a settop type box to alert on. If you are having the box broken into and defaced, alerting when it happens just tells you that you were already hacked. Work on locking down the system (turn of anything you don't need) and then look at what's still running and what logs it generates. I know this seems unhelpful, but even when you spend 7 figures on a log alerting system, default rules are still worthless, and you spend a lot of time creating custom rules (or a lot of money paying the vendor professional services to write the rules :-) David Lang On Mon, 7 Apr 2014, Tim Peiffer wrote: > I am trying to extend the SEC method into areas that I have no familiarity. > > My co-worker doesn't have a set of requirements yet other than having a > hacked web status page. I was hoping to have him use examples an aid to the > requirements gathering phase. Once he can articulate the requirements, I > could then construct the parsers. > > Beyond asking for examples are there any stories that this list would be > willing to share about using SEC to monitor multicast or broadcast television > systems? > > Tim > > On 4/6/14, 7:11 PM, David Lang wrote: >> No, there are not rules already defined, you would first need to decide >> what it is that you want to monitor for, and what you want to do when you >> detect those things. >> >> Pre-built rulesets in alerting engines are seldom useful for anything other >> than examples. There are very few cases where two people want to do the >> exact same thing in response to the exact same conditions. >> >> What is it that you want to monitor for? >> >> David Lang >> >> On Sun, 6 Apr 2014, Tim Peiffer wrote: >> >>> I have a co-worker that is trying to introduce me to Raspberry Pi and >>> his facilities for monitoring an HD TV headend. Based on some of the >>> stuff I have seen, it is a good candidate for monitoring with SEC. Are >>> there already rulesets defined for the Hauppauge Win-TV - based on >>> Auvitek AU8522 QAM/8VSB Frontend? >> >> > > > ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
