{"id":101,"date":"2007-06-17T10:29:41","date_gmt":"2007-06-17T15:29:41","guid":{"rendered":"http:\/\/raffy.ch\/blog\/2007\/06\/17\/afterglow-158-security-data-visualization\/"},"modified":"2007-06-17T10:33:34","modified_gmt":"2007-06-17T15:33:34","slug":"afterglow-158-security-data-visualization","status":"publish","type":"post","link":"https:\/\/raffy.ch\/blog\/2007\/06\/17\/afterglow-158-security-data-visualization\/","title":{"rendered":"AfterGlow 1.5.8 – Security Data Visualization"},"content":{"rendered":"

Finally! I worked on this AfterGlow<\/a> release forever. I submitted a few checkpoints to CVS before I felt read to released AfterGlow 1.5.8<\/a>. I highly recommend upgrading to 1.5.8. It has a few bugfixes, but what you will find most rewarding is the new color assignment heuristic and the capability to change the node sizes. Here is the complete changelog:<\/p>\n

06\/10\/07 Version 1.5.8
\n- Nodes can have a size now:
\n(size.[source|target|event]=<expression returning size>)
\nSize is accumulative! So if a node shows up multiple times, the
\nvalues are summed up!! This is unlike any other property in
\nAfterGlow where values are replaced.
\n- The maximum node size can be defined as well, either with a property:
\n(maxnodesize=<value>)
\nor via the command line:
\n-m=<value>
\nThe size is scaled to a max of 'maxsize'. Note that if you
\nare only setting the maxsize and no special sizes for nodes
\nAfterglow will blow the nodes up to optimal size so the labels
\nwill fit.
\nThere is a limit also, if you want the source nodes to be a max of say
\n1, you cannot have the target nodes be scaled to fit the labels. They
\nwill have a max size of 1 and if you don't use any expression, they will
\nbe of size 1. This can be a bit annoying ;)
\nBe cautious with sizes. The number you provide in the assignment is not the actual size
\nthat the node will get, but this number will get scaled!
\n- One of the problems with assignments is that they might get overwritten with later nodes
\nFor example, you have these entries:
\nA,B
\nA,C
\nand your properties are:
\ncolor=\"blue\" if ($fileds[1] eq \"B\")
\ncolor=\"red\"
\nyou would really expect the color for A to be blue as you specified that explicitly.
\nHowever, as the other entry comes later, the color will end up being red. AfterGlow takes
\ncare of this. It will determine that the second color assignment is a catch-all, identified
\nby the fact that there is no \"if\" statement. If this happens, it will re-use the more specific
\ncondition specified earlier. I hope I am making sense and the code really does what you would
\nexpect ;)
\n- Define whether AfterGlow should sum node sizes or not.
\n(sum.[source|target|event]=[0|1];)
\nby default summarization is enabled.
\n- Added capability to define thresholds per node type in properties file
\n(threshold.[source|event|target]=<value>;)
\n- Added capability to change the node shape:
\nshape.[source|event|target]=
\n(box|polygon|circle|ellipse|invtriangle|octagon|pentagon|diamond|point|triangle|plaintext)
\n- Fixed an issue where, if you use -t to only process two columns
\nand you can use the third in the property file for size or color.
\nThe third column was not carried through, however. This is fixed!
\n- The color assignment heuristic changed a bit. Along the same lines that the size assignment works.
\nCatch-alls are not taking presedence anymore. You might want to take this into account when defining
\ncolors. The catch-all will only be used, if there was never a more specific color assignment that
\nwas evaluated for this node. For example:
\ncolor=\"gray50\" if ($fields[2] !~ \/(CON|FIN|CLO)\/)
\ncolor=\"white\"
\nThis is used with a three-column dataset, but only two are displayed (-t). If the first condition
\never evaluated to true for a node, the last one will not hit, although the data might have a node that
\nevaluates to false in the first assignment and then the latter one would grip. As a catch-all it does
\nget superior treatment. This is really what you would intuitively assume.
\n- Just another note on color. Watch out, if you are definig colors not based on the fields in the
\ndata, but some other conditions that might change per record, you will get the wrong results as
\nAfterGlow uses a cache for colorswhich keys off the concatenation of all the field values. Just
\na note! Anyone having problems with this? I might have to change the heuristic for caching then. Let
\nme know.
\n<\/code>
\n[tags]afterglow, visualization, security log analysis, security visualization[\/tags]<\/p>\n","protected":false},"excerpt":{"rendered":"

Finally! I worked on this AfterGlow release forever. I submitted a few checkpoints to CVS before I felt read to released AfterGlow 1.5.8. I highly recommend upgrading to 1.5.8. It has a few bugfixes, but what you will find most rewarding is the new color assignment heuristic and the capability to change the node sizes. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,2],"tags":[],"class_list":["post-101","post","type-post","status-publish","format-standard","hentry","category-log-analysis","category-visualization"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t